Need to do Reload objects to get string/c strings to take effect

#1

I'm working with an LCD printout function, and I have my strings stored in the factory string/c objects, which have the actual string as an attribute. However, changing the string and clicking Live does not cause the actual string that is output to change. I need to do a Reload objects, and after that the string generated after clicking Live reflects the actual string entered. This does not seem correct to me, I would expect any attributes changed to be reflected next time Live is clicked.

I should mention that I am using the development version (latest commit on 13/3).

#2

I can't reproduce this, could you check with this patch?
string-attr-test.axp (1.8 KB)

#3

Yes, it's the same, but it seems more complex than I initially thought.

If I open the patch, click live, verify that I get Hello world in the log window, then unclick Live, edit the string, click Live again, I still get Hello world. If I however unclick live and then click it again, I get the new string.

(I should mention that currently I'm running my P6 fork, I should really verify this on the Axoloti Core, so it's not a question of "this change should not affect that", but I do notice that even after changing the string and clicking live, xpatch.cpp still contains the old string, so it appears the problem is on the host side).

#4

Do you seen any java exceptions (launch Axoloti from a terminal)?
Are you sure it only fails to update the string, rather than the whole patch?

#5

I can't see any java exceptions in the terminal or in the log window.

One thing I did notice though was this:

...
INFO: Done compiling patch
Apr 06, 2016 12:24:50 AM qcmds.QCmdProcessor$4 run
INFO: Start uploading patch
Apr 06, 2016 12:24:50 AM axoloti.USBBulkConnection UploadFragment
INFO: block uploaded @ 0x20011000 length 3272
Apr 06, 2016 12:24:50 AM qcmds.QCmdProcessor$4 run
INFO: Done uploading patch
Apr 06, 2016 12:24:50 AM qcmds.QCmdProcessor$4 run
INFO: Starting patch...
Apr 06, 2016 12:24:50 AM qcmds.QCmdProcessor$4 run
INFO: Done starting patch
Apr 06, 2016 12:24:50 AM qcmds.QCmdProcessor$4 run
INFO: Start locking
Apr 06, 2016 12:24:50 AM qcmds.QCmdProcessor$4 run
INFO: Done locking
tablename change hello worldee
Apr 06, 2016 12:24:54 AM axoloti.USBBulkConnection processByte
INFO: Axoloti says: hello world
Apr 06, 2016 12:24:55 AM axoloti.USBBulkConnection processByte
INFO: Axoloti says: hello world
Apr 06, 2016 12:24:55 AM axoloti.USBBulkConnection processByte
INFO: Axoloti says: hello world

Notice how it says 'tablename change hello worldee' (which is what I changed the name to, by just adding to e's at the end), after it has uploaded the patch (and that the Axoliti still reports the old name).

I can't be certain it's just the string that it fails to update, though I haven't noticed it when changing combo attributes or spinners.

Partly that's due to my development cycle: in order to be sure that a change I've done in the object editor actually takes effect, I do three things: a) click Save in the object editor, 2) click Reload objects, 3) Use Replace on the actual object (per someone's suggestion I have the original filename, say lcdctrl.axo, and an alternative, as a linke, say lcdctrl_.axo, and I swap between those to get the Patrcher to reload the source for the object). So I usually do click Reload objects as part of this cycle, unless I'm just changing the attributes, so I would seldom notice the problem.

#6

You seem to be able to modify the string after starting the patch, normally starting the patch disables modification of (string) attributes. Live updating of strings is not supported.
Development cycle: if you use patch/object and use the built-in object editor, changes are propagated the next time you click live...

#7

No, I'm only modfying the strings when the patch is stopped. I agree that the log above makes it look otherwise, but I had completed my string edit by the time I started the patch.

I see. Seems very handy, yes, thanks!

I also learnt something else: I've missed some form of debugging printout functionality, thinking it perhaps must be done via a serial port (as I saw some reference to a debug port in the Axoloti firmware code), but now I see there's LogTextMessage() which outputs to the Axoloti Patcher log window.
.
Regarding patch/object: Is there some magic behind the scenes going on, because I can't see in the XML code what causes the edit button to appear (nor how to remove it once the object is finished and I want to turn it into an ordinary ("non-edit") object)?

#8

in the development branch, the object can be 'converted', by using the new 'add to library' option on the file menu. (similarly objects can be converted to an embedded form, using the covert to embedded object option)

(yes, there is some specific support for patcher/object in the object editor)

#9

Ah, so the Edit button in the UI of the object goes away when you do 'add to library'? And conversely comes back if you embed an object? Or does it (one or both) only happen if the object id is 'patcher/object'?

#10

yes and yes ... thats exactly what happens.

(theres still some room for improvement still, but I think as a workflow it works reasonable well now)