I am not sure why but in OM 6.9 I can’t get the reactif objects such as coll or timed-coll to “start receiving.”
Is right-click still the command to activate them?
Thank you!
Michele
Hi Michele
You must use the ‘r’ key
right-click/“start receive” is only for MIDI-in and osc-receive boxes which require a “receive” thread to run.
thanks Jean, just select and press ‘r’? that doesn’t seem to work for me…
you probably need to activate the reactive feature in the OM general preferences.
Thanks Jean. It works now.
I am having a hard time re-initiating the coll object. I know I have to use the third input but giving it a nil value won’t do it.
I think this feature really changes a lot in terms of what we can do with OM, thank you for developing it!
the third input is a little bit tricky : it needs to be connected to something not-NIL in order to init. But if it is permanently connected, then it will always reinitialize.
So, typically you would rather connect it to a BUTTON object, so that it is TRUE inly when the button is pushed
or to a message coming through MIDI-in or OSC-RECEIVE, routed via ROUTE or ROUTE-OSC…
One problem with the button object is that when coll is set on reactif (by pressing r) it continuously re-evaluate its init input and continuously erases its contents.
At least that is what’s happening to me.
ok: this is how I did it. I had issues with using a single OSC port since some messages seemed to get “stuck”: I tried to send a “reset” message but somehow that did not overwrite the previous message. So I used a different OSC port and a route object as Jean had suggested. Since I am sending lists from MaxI just need to make sure that the reset message is sent before the “go” message which “opens the door” for the dump message. Since “go” does not satisfy the “reset” test in the route object it will cause the second outlet of route to output nil and therefore allow coll to retain its incoming messages. The problem I was having was that coll would continously evaluate whatever message it had in the third inlet causing it to “lose” of its content.
I think my screenshot was wrong with the button box: it is the 2ND output that must be connected to coll. This one is T when pressed and NIL otherwise.
Jean
About your patch with OSC:
- you may prefer the ROUTE-OSC object, which will prevent you from doing all the message processing and allow youto select diretly “reset”
- can’t you use the same receive/port and just add another in/output test ?
Hi Jean, I am trying your solution and it looks like it should work, except that I have been having many problems with the reactivity of coll. In general sometimes it reacts and sometimes it does not. It seems like it gets stuck. Other times I get coll to react to a init message but then the chord-seq object does not react to it even if it is on r mode. Is this a problem that other people have been experiencing?
After a few trials, I realized that my solution with two OSC ports, one for the message and one for the reset command, is the only one that really works for me. I know it should be possible to use only one port but in my case it does not work and I am not sure why.
Hi Michele.
About your button option, you should lock the button box (with ‘b’) in order to avoid it to be reinitialized all the times.
I think I noticed some strange behaviours myself with the coll box. When it happens you can usually remove and create a new box. Of course this is not a satisfactory solution, but it can be helpful in the meantime.
Jean