[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-users] Modality toolkit, collectiveIn and XY-sliders ?
Hi again,
I just reread the documentation on MKtlElementGroup, and it is actually intentional behavior:
setting the value by collective does not trigger the actions of the individual elements.
Recommendations:
For maximum efficiency of incoming message treatment,
-> do all mapping in the collective action itself.
This is esp. helpful for continuously polling controllers, such as gyros, IMUs.
For convenience of group actions and individual element actions,
-> add that behavior to the collective action as show below.
... this information should probably go into a Modality tutorial file :-)
best adc
> On 15/12/2018, at 12:06 , alberto.decampo <alberto.decampo@xxxxxxxxx> wrote:
>
>
>
>> On 15/12/2018, at 10:28 , mail@xxxxxxxxxxxxxxxxx wrote:
>>
>> Okay, to be honest I'm still struggling with this.
>>
>> I think that I have trouble conceptually understanding the connection(s) between the collectives part and the descriptions in elementsDesc and specifically what info goes where.
>> In the example below, this is causing me some trouble. This code evaluates fine, and according to the trace it receives the osc messages and understands them accordingly. But it doesn't trigger the action that I added. Why is that? What did I get wrong?
>> thanks !!
>>
>
> Ahoi,
> you are right to be confused
> - I did not really test that the individual actions work, and they really don't, which is a bug in Modality.
> So, here is a quick fix for you, so you can continue working now;
> you can take the fix out when this bug is fixed in the Modality-toolkit.
>
> Please let me know if this works!
>
> best adc
>
> (
> d = (
> idInfo: "osc app",
> name: \sccontroller1,
> netAddrInfo: (
> recvPort: NetAddr.langPort,
> srcPort: 6666,
> ipAddress: nil
> ),
> deviceType: \phoneApp,
> protocol: \osc,
> collectives: (
> sliders: (
> oscPath: '/xy/xy1',
> elements: [ [\sl, \x], [\sl,\y]], // the order in this array determines the order how the message is parsed
> ioType: \in
> )
> ),
> elementsDesc: (
> elements: [
> // Buttons
> (
> key: 'bt',
> shared: (
> type: 'button',
> ioType: \in,
> spec: \but
> ),
> elements:[
> (oscPath: '/xy/rec'),
> (oscPath: '/xy/play'),
> (oscPath: '/xy/stop'),
> (oscPath: '/xy/prev'),
> (oscPath: '/xy/next')
> ]
> ),
> // XY Sliders
> (
> key: 'sl',
> shared: (
> elementType: 'slider',
> ioType: \collectiveIn,
> spec: \unipolar,
> ),
> elements:[
> (key: \x),
> (key: \y),
> ]
> ),
>
> ]
> )
> );
>
> m.free; m = MKtl.new(\scc1, d);
>
> // m.device.updateSrcAddr("192.168.43.1", 60310);
>
> m.trace;
>
> /* OSCFunc.trace(true); */
> )
>
>
> m.elAt(\sl); // the slider group
> m.trace;
> m.gui;
> n = NetAddr.localAddr;
> // tell m to listen to local osc from SC itself:
> m.device.updateSrcAddr(n.hostname, n.port);
>
> // this changes a button value
> n.sendMsg('/xy/rec', 1);
> n.sendMsg('/xy/rec', 0);
>
> // should change the values in sl1, sl2
> n.sendMsg('/xy/xy1', 0.5, 0.5);
> n.sendMsg('/xy/xy1', 0.2, 0.8);
>
>
> // give the sl group a debug post action,
> // could also be used to set two values of something
> m.elAt(\sl).action = { "sl group action runs".postln };
>
>
> // give slider x and y separate example actions for testing
> m.elAt(\sl, \x).action = { |sl| "sl X action ...".postln };
> m.elAt(\sl, \y).action = { |sl| "sl Y action ...".postln };
>
>
> /// ... as Modality is ATM, sl group, x, y actions do not run!
> n.sendMsg('/xy/xy1', 0.5, 0.5);
> n.sendMsg('/xy/xy1', 0.2, 0.8);
>
>
> /// QUICK AND DIRTY FIX - should really be fixed in Modality !
>
> // tell the collectives action to ...
> m.collectivesDict[\sliders].action = { |coll|
> // post debug message for now ...
> "collective 'sliders' action runs".postln;
> // trigger the group action once ...
> m.elAt(\sl).action.value(m.elAt(\sl));
> // and trigger the individual element actions
> coll.do { |elem| elem.action.value(elem) };
> };
>
> ///// now group ction and indiv elem actions run
> // when a simulated osc message comes in:
> n.sendMsg('/xy/xy1', 0.5, 0.5);
> n.sendMsg('/xy/xy1', 0.2, 0.8);
>
>
> // ... and now, switch addr back to phone app
> m.device.updateSrcAddr("192.168.43.1", 60310);
>
>
>>
>>
>> s.boot;
>> (
>> d = (
>> idInfo: "osc app",
>> name: \sccontroller1,
>> netAddrInfo: (
>> recvPort: NetAddr.langPort,
>> srcPort: 6666,
>> ipAddress: nil
>> ),
>> deviceType: \phoneApp,
>> protocol: \osc,
>> collectives: (
>> xy1: (
>> oscPath: '/1/xy1',
>> elements: [[\pg1, \sl, \x], [\pg1, \sl, \y] ],
>> ioType: \in
>> ),
>> ),
>> elementsDesc: (
>> elements: [
>> // Page1
>> (key: 'pg1',
>> elements: [
>> (key: 'sl',
>> shared: (
>> elementType: 'slider',
>> ioType: \collectiveIn,
>> spec: \unipolar,
>> ),
>> elements:
>> [ (key: \x), (key: \y) ]
>> )
>> ]
>> )
>> ]
>> )
>> );
>>
>> m.free; m = MKtl.new(\sccontroller1, d);
>>
>> m.trace;
>>
>> m.resetActions;
>>
>> // See elements
>> m.postElements
>>
>> // Okay, it exists!
>> m.elAt(\pg1, \sl, \x);
>>
>> // Add an action to see if it works
>> m.elAt(\pg1, \sl, \x).action = { |sl| "sl X action runs - val is ".post; sl.value.postln };
>>
>> // Send a test message
>> n = NetAddr.localAddr;
>> m.device.updateSrcAddr(n.hostname, n.port);
>>
>> // Send message. This is received according to trace, but the action above isn't triggered. Why?
>> n.sendMsg('/1/xy1', 0.2, 0.8); // Posts: "MKtl('sccontroller1') osc xy1 > [ 0.2, 0.8 ] | type: nil "
>> )
>>
>>
>> On 14/12/2018 12.16, alberto.decampo@xxxxxxxxx wrote:
>>> the collective stuff is a real braintwister ...
>>> luckily Marije figured out how to implement it correctly!
>>>
>>>
>>>
>>>> On 14/12/2018, at 11:42 , mail@xxxxxxxxxxxxxxxxx
>>>> wrote:
>>>>
>>>> This seems to do it for me. I got confused about all this collective in stuff. But your code does the trick – thanks for the inspiration!
>>>> On 14/12/2018 11.36,
>>>> alberto.decampo@xxxxxxxxx
>>>> wrote:
>>>>
>>>>> m.elAt(\sl);
>>>>> m.trace;
>>>>> m.gui;
>>>>> n = NetAddr.localAddr;
>>>>>
>>>>> // tell m to listen to local osc from SC itself: ( I dont have the app)
>>>>> m.device.updateSrcAddr(n.hostname, n.port);
>>>>>
>>>>> // simulate what the app sends from a button
>>>>> // this changes button values
>>>>> n.sendMsg('/xy/rec', 1);
>>>>> n.sendMsg('/xy/rec', 0);
>>>>>
>>>>> // simulate what the app sends from the xy slider
>>>>> // this changes both values in sl1, sl2 from
>>>>> n.sendMsg('/xy/xy1', 0.5, 0.5);
>>>>> n.sendMsg('/xy/xy1', 0.2, 0.8);
>>>>>
>>>>>
>>>>> ////// is this what your question was? /////////
>>>>> // give slider x and y separate actions:
>>>>> m.elAt(\sl, \x).action = {
>>>>> |sl|
>>>>> "sl X action runs - val is ".post; sl.value.postln };
>>>>> m.elAt(\sl, \y).action = {
>>>>> |sl|
>>>>> "sl Y action runs - val is ".post; sl.value.postln };
>>>>>
>>>>>
>>>> --
>>>> Best Regards,
>>>> Mads Kjeldgaard
>>>>
>>>>
>>>
>>> _______________________________________________
>>> sc-users mailing list
>>>
>>> info (subscription, etc.):
>>> http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
>>>
>>> archive:
>>> https://listarc.bham.ac.uk/marchives/sc-users/
>>>
>>> search:
>>> https://listarc.bham.ac.uk/lists/sc-users/search/
>> --
>> Best Regards,
>> Mads Kjeldgaard
>>
>
_______________________________________________
sc-users mailing list
info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/