aaron

I have created an application where the user uses umenus to create connections between RFID tags and audio samples. The RFID tags and audio samples will change so, of course, the contents of the umenus need to change too. Since Save is greyed out in Runtime, is there any other way to save changes to umenus in Runtime?

I have created an application where the user uses umenus to create connections between RFID tags and audio samples.  The RFID tags and audio samples will change so, of course, the contents of the umenus need to change too.  Since Save is greyed out in Runtime, is there any other way to save changes to umenus in Runtime?  

saving-changes-to-umenu-in-runtime

Thanks, I did end up using coll. I was just hoping there was a less clunky way of doing it. I wonder why not let users save changes in Runtime?

Thanks, I did end up using coll.  I was just hoping there was a less clunky way of doing it.  I wonder why not let users save changes in Runtime?    

On 23 Nov 2008, at 16:20, Aaron Miller wrote:

> I wonder why not let users save changes in Runtime?

Then who would bother buying the full version?

(But then, since you are free to edit coll files, Javascript sources, 

etc. as well as work in a variety of scripting languages, and 

(presumably - I've not tried it) talk to Max's internal SQLite 

database, there's a lot you can do with just the Runtime, assuming 

that someone has already build a framework patcher.)

(But then, since you are free to edit coll files, Javascript sources,  
etc. as well as work in a variety of scripting languages, and  
(presumably - I've not tried it) talk to Max's internal SQLite  
database, there's a lot you can do with just the Runtime, assuming  
that someone has already build a framework patcher.)

Nick Rothwell / Cassiel.com Limited
www.cassiel.com
www.myspace.com/cassieldotcom
www.last.fm/music/cassiel
www.reverbnation.com/cassiel
www.linkedin.com/in/cassiel
www.loadbang.net


Seriously? Anyone who wanted to EDIT a patch would buy the full version.

Seriously?  Anyone who wanted to EDIT a patch would buy the full version.


Anyone who wanted to EDIT a patch would buy the full version.

Right, you can't EDIT in Runtime, but you can certainly save all sorts of text and data files and then reload them, like you did with [coll]. The actual Runtime patch isn't changed, but the data it accesses can be.

Interesting that through [thispatcher] [mousestate] and some work, you could actually make a Runtime patch which would allow the user to create objects and patch all kinds of things together. Could this tweaked patch be saved somehow? Any way to dump the current patch contents from a Runtime into a text file? Just curious, it's a lot of work to do this just for kicks... but it might give non-full-version users a taste of how things work.

Anyone who wanted to EDIT a patch would buy the full version. 

Rather than trying to save the user-created patch after it's done, just keep a record of the messages used to create it as they are generated, and save that to disk from coll or text or js or whatever. Then at reload, re-run those object creation/connection messages.

Ah, of course. That could also be interesting to be able to play it back at different speeds etc. to get a feel for the patching process.

I also thought of something similar for tutorials for a patch: instead of big, bulky screen-capture movie files, just use a [mtr] to record the example interactions you want to demonstrate, then the user can play that mtr file back and watch the interaction. There would be some losses, like if you paint in a multislider, but most interactions can be captured readily. If you want the cursor in there, you could mtr the mousestate and use pupdate (pointer-update) to animate the mouse too.

-->
Rather than trying to save the user-created patch after it's done, just keep a record of the messages used to create it as they are generated, and save that to disk from coll or text or js or whatever. Then at reload, re-run those object creation/connection messages.
-->

I also thought of something similar for tutorials for a patch: instead of big, bulky screen-capture movie files, just use a [mtr] to record the example interactions you want to demonstrate, then the user can play that mtr file back and watch the interaction. There would be some losses, like if you paint in a multislider, but most interactions can be captured readily. If you want the cursor in there, you could mtr the mousestate and use pupdate (pointer-update) to animate the mouse too.


Saving changes to umenu in Runtime