another [coll] to [pattr] js
Nov 21, 2010 at 11:49am
another [coll] to [pattr] js
It works by living in between [pattr] and [coll]. You can send it any command you would send a [coll] except for “delete”, which is a reserved internal js function name (use “del” instead, it will forward the proper command to the [coll] it is connected to). It updates the pattr with the new coll every time it receives one of the messages it understands. There is a list of functions which it merely passes on to the coll, without making any changes in its internal structuring of the data. It is also capable of retrieving the information directly from [coll] if the two are connected properly. The first, second, and fourth outlets of the [coll] must be connected to the second, third and fourth inlets of [js coll_pattr.js] for [coll] to send its data to the [pattr]. The function “collect” will read the current data from the [coll] object.
“Nearly”…what does that mean? I don’t know yet. Some ordering will probably get lost….time will tell. Check it out.
setinletassist(0, “pattr bind and incoming messages to coll”);
function swap(a, b)
– Pasted Max Patch, click to expand. –
Copy all of the following text.Then, in Max, select New From Clipboard.
Nov 22, 2010 at 6:40am
hey, i checked it, i’m not sure what you mean with “If there is no need for collecting data from the [coll]“.
this is a more elegant way, without disput. but is it faster then dumping
Nov 22, 2010 at 7:49pm
Exactly: if all the data in the [coll] was input through the js, there is no need for the outlets of the [coll] to be connected to the js (except for one case: sort).
“collect” replaces the contents of the [pattr] with the current data in the [coll]. So for instance, say you edit the [coll] via text edit, or you are adding a new [coll] file to a project and want to get its contents into the [pattr], you would use “collect” to get the current data. “dump” would do the same thing.
I don’t know that its any faster, honestly. It should be more efficient. I’ve just started using it in my patches, but I have to redesign some things to get it to work optimally. I was using [matrixctl] connected to a [pattr] previously to store settings, and this new method definitely works better for that sort of thing. I’m still using [textedit] for smaller lists, though: basically anything that doesn’t need the [coll] functions. This should be faster, since there’s no need to dump the [coll] again after changes are made in order to reflect the change in the [pattr].
Nov 24, 2010 at 2:28pm
Thanks for this patch/script. very helpful.
One thing does not work as expected: I’ve tried to store an array(?) in the first place. So in the [coll] editor appears the following line:
1, “array at first” x y z;
After the coll was restored by the [js] it look like that:
1, x y z;
Any idea how to fix this ?
Nov 24, 2010 at 3:42pm
ok, this could be a solution:
I’ve added these lines
in this function:
Nov 24, 2010 at 7:16pm
Thanks for the observation: I hadn’t noticed this, so I’ll try to figure out what’s up and repost a solution. I definitely want to know about any problems with this thing before I package it in all the Monomodular patches.
One thing: if you change any of the code in the “mux” function, make sure that there is a “^” placed in between each item in the coll, as well as at the beginning and end of the value stored in the [pattr].
I expect it will probably need some more fine tuning….please, if anyone else notices any weird behaviour, let me know; I haven’t had a lot of time to test out all the different functionality in real world situations.
edit:: thanks again for the code…now that I’m looking at your solution, I realize I wouldn’t have even thought of that without hours of staring and scratching. :)
Sep 3, 2012 at 12:25am
Someone was interested in this, and I noticed that my original js code snippet got garbled when Cycling updated the forums last. Here’s a link to a m4l frozen patcher that displays some of the functionality of this; I haven’t had time to retest it, but it seems to work ok at first glance. Let me know if anything doesn’t work right:
Sep 3, 2012 at 5:19pm
The above mentioned “collect an array in the first place” bug is back. :-)
Have a look at the appended M4L device. It shows you exactly how to reproduce it.
Sep 4, 2012 at 8:14pm
Ahhh….thanks for that. Bad file references, the newest js must’ve gotten lost in the shuffle somehow. I’ll update and repost shortly…..
Sep 9, 2012 at 9:49pm
Here’s an updated version with Stan’s fix….I spent a few minutes testing it, and it should work as expected now.
Sep 9, 2012 at 11:47pm
:)))))))))) u are my hero !!!
Sep 18, 2012 at 10:39am
Sep 18, 2012 at 1:06pm
ive spotted that this line cause the problem
Sep 21, 2012 at 1:47pm
Thanks, I’ll try to have a look at this today or tomorrow.
Sep 21, 2012 at 3:12pm
is there a way to improve JS iteration process too ? ive noticed a long hangs (around 2 -3 minutes) when iterating elements into an array that gets over 1000 steps . this efficiency issue has something to do with JS processing within Max ? i know that JS is slower over native patching , C or Java, but such hangs are rare in the computing world ,especially when we are not dealing with huge audio/visual data streams ,just some characters
Sep 22, 2012 at 5:50pm
Sounds like it’s probably not JS that’s causing the lag….it’s more likely a problem with sending such long lists as a blob to the [pattr]. Unfortunately, there’s probably not much to be done about this except reduce the number of times your making changes and restoring these “long lists”.
If you can send me an example patch showing what’s going on, I’ll check and see what’s going on….I’ve been travelling lately, so all my “freetime coding” has been a bit curtailed…..
Sep 22, 2012 at 7:18pm
well , ive done a workaround with your JS .ive reproduced your JS logic directly in max . ive bypassed dumping/collecting . im dumping data with max elements in right order and list preparation so it remains the same as your JS conditions but without collstore in action, directly to pattr . it takes around 30ms now ,not 2 minutes .
You must be logged in to reply to this topic.