working example of saving js state in M4L

    parkingsun
    Apr 01 2013 | 7:05 pm
    I've been trying to work out how to get a JS script to remember some internal state in an M4L device so that innter patch working involving javascript can be, e.g. save in presets etc.
    I've had no luck yet. I tried to do an M4L version of the notorious "cowbell" example in the tutorial, using "getvalueof()/setvalueof()" JS functions in a @parameter_enable 1 JS object, but my JS object never seems to recall data with the patcher (i.e. when you call the "howmanycowbells" function, it does not recall a different version for each device.
    In the interim I've been working around it by having the javascript object write out the value of getvalueof() to a pattr in parameter mode, and then an initialisation i get the pattr to send that data back again with "setvalueof" prepended.
    For your convenience my javascript is included below so that you can inform me how I've been a dunderhead.
    comments, critique gratefully accepted.
    autowatch = 1;
var numcowbells = 1;

function cowbells(a)
{
	numcowbells = a;
	notifyclients();
}

//AFAICT this is only used for saving JS state with the patcher itself, not in the M4L version
function save()
{
	embedmessage("cowbells", numcowbells);
}

function howmanycowbells()
{
	post("numcowbells", numcowbells);
	outlet(0, numcowbells);
}

function getvalueof() {
	return numcowbells;
}

function setvalueof(a) {
	cowbells(a);
}
    • Lee
      Apr 02 2013 | 3:31 am
      Hi, the getvalueof() and setvalueof() functions interact with the pattr system... if you attach the middle outlet of an 'pattr @parameter_enable 1' to the first inlet of your js then everything should be good.....
      The save() function you have is for storing state in a patcher and isn't needed here....
      Hope this helps...
    • parkingsun
      Apr 02 2013 | 1:43 pm
      Ahhh. Thank you Lee.
      Got it. So @parameter_enable 1 doesn't really do anything with JS - I should defer all that stuff to a pattr, for which @parameter_enable 1 does what one expects. OK.
      Bonus points if anyone can tell me what @parameter_enable 1 DOES do for a javascript object.
    • Lee
      Apr 02 2013 | 6:14 pm
      pattr objects normally need a pattrstorage object in order to determine where the information is stored.... the pattr object with @parameter_enable 1 indicates that the information should be stored within the patch and you don't need to provide an independent pattrstorage object...
    • Lee
      Apr 02 2013 | 6:45 pm
      for above post, should add that the @parameter_enable 1 is part of the pattr storage for m4l...
    • parkingsun
      Apr 02 2013 | 10:44 pm
      Thanks, Lee for diving back in to it again!
      I think I perhaps could have phrase my flippant final question better.
      To do that now, yes I understand that @parameter enable tells the pattr to store information with the preset rather than in the patch. However, my question is, rather, why it seems to behave differently between a JS object and other objects. So if I put a [pattr] or, say, a [flonum] in @parameter_enable 1 mode, then they instantly and magically behave like standard live interface objects such as [live.dial], in that they store their state in the preset. If, however, I create a [js @parameter_enable 1] object, it seems, if I am understanding you correctly, to additionally require to be attached to a [pattr @parameter_enable 1] object to save its state, and does not save that state itself. Therefore, as far as I understand, @parameter_mode 1 doesn't do anything for JS objects, and may as well be ignored.
      The patch works fine, by the way, using your [pattr @parameter_enable 1] hack! At this point I'm more trying to understand rather than fix anything.
    • Lee
      Apr 03 2013 | 4:59 am
      Ah, I see what you mean... I misunderstood your post... I was not aware that you could supply @parameter_enable 1 as an attribute to a js object - I guess this should behave as you expect... I'll give this a try when I have a few mins...