jcom.remote.module.to and scheduler in 0.5.7

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

jcom.remote.module.to and scheduler in 0.5.7

Evgeniy Chernyy
Hello, folks!

I working on a big patch, which should contain a lot of little modules (about 50). I want to control those modules from some place passing messages to the [jcom.send jcom.remote.module.to] object. So my question: what happens with message when I send it through jcom.remote.module.to? Will it move from scheduler to the queue? Will the depth-first rule work?

Best,
Eugene



------------------------------------------------------------------------------
_______________________________________________
Jamoma-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-users
Reply | Threaded
Open this post in threaded view
|

Re: jcom.remote.module.to and scheduler in 0.5.7

Trond Lossius
Administrator
Hi Eugene,

> I working on a big patch, which should contain a lot of little modules (about 50). I want to control those modules from some place passing messages to the [jcom.send jcom.remote.module.to] object. So my question: what happens with message when I send it through jcom.remote.module.to? Will it move from scheduler to the queue? Will the depth-first rule work?

It will not move to any other queue, so if it is in the scheduler queue, it will stay there.

When the message is sent to jcom.remote.module.to it will be received by the jcom.hub object in the appropriate module. This will then send it on to the appropriate jcom.parameter or jcom.message object within the module. Once the parameter value has been updated the new value is passed from the outlet of com.parameter, then from the appropriate outlet of jcom.in (or jcom.in~) and finally passed out again from the outlet of jcom.hub. Generally the idea is that each module will have a unique name, and the same goes for each of the parameters inside the module, so that there only really should be one target location for the message.

When you want to control many parameters in many modules in a specified sequence, you can do so by sending the messages sequentially (e.g. from the jmod.cueScript module). If you have the sequence sorted correctly in the cue, the messages will be sent in the same sequence, and hence you have control of what messages are sent first and last. This is typically how I initiate my patches with many modules, e.g. in order to ensure that I have set the correct number of speakers for spatialisation before starting to describe the position of any of them.

I hope this helps!

Best,
Trond
------------------------------------------------------------------------------
_______________________________________________
Jamoma-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-users
Reply | Threaded
Open this post in threaded view
|

Re: jcom.remote.module.to and scheduler in 0.5.7

Evgeniy Chernyy
Thanks Trond,

That was very helpful. So, the jcom.remote.module.to is the same as regular send/receive. So I guess, the same rule works when receiving messages through jcom.remote.module.from?

> When you want to control many parameters in many modules in a specified sequence, you can do so by sending the messages sequentially (e.g. from the jmod.cueScript module).

Yes, cue scripts are great — they are a truly lifesavers when managing state of the complex patch. But in my current patch I use jcom.send to algorithmically control a lot of modules in real-time. Maybe I introduce interaction with performer also. So the timing in this case is important.

Thanks for help!

Best,
Eugene

On Nov 6, 2014, at 9:05 PM, Trond Lossius <[hidden email]> wrote:

> Hi Eugene,
>
>> I working on a big patch, which should contain a lot of little modules (about 50). I want to control those modules from some place passing messages to the [jcom.send jcom.remote.module.to] object. So my question: what happens with message when I send it through jcom.remote.module.to? Will it move from scheduler to the queue? Will the depth-first rule work?
>
> It will not move to any other queue, so if it is in the scheduler queue, it will stay there.
>
> When the message is sent to jcom.remote.module.to it will be received by the jcom.hub object in the appropriate module. This will then send it on to the appropriate jcom.parameter or jcom.message object within the module. Once the parameter value has been updated the new value is passed from the outlet of com.parameter, then from the appropriate outlet of jcom.in (or jcom.in~) and finally passed out again from the outlet of jcom.hub. Generally the idea is that each module will have a unique name, and the same goes for each of the parameters inside the module, so that there only really should be one target location for the message.
>
> When you want to control many parameters in many modules in a specified sequence, you can do so by sending the messages sequentially (e.g. from the jmod.cueScript module). If you have the sequence sorted correctly in the cue, the messages will be sent in the same sequence, and hence you have control of what messages are sent first and last. This is typically how I initiate my patches with many modules, e.g. in order to ensure that I have set the correct number of speakers for spatialisation before starting to describe the position of any of them.
>
> I hope this helps!
>
> Best,
> Trond
> ------------------------------------------------------------------------------
> _______________________________________________
> Jamoma-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jamoma-users


------------------------------------------------------------------------------
_______________________________________________
Jamoma-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-users
Reply | Threaded
Open this post in threaded view
|

Re: jcom.remote.module.to and scheduler in 0.5.7

Pascal Baltazar-5
That’s been a while since I used 0.5, but I think you can use [jcom.send /moduleName/parameterName] to address your parameters directly… And I think they’re configurable, too… so you can change the address on the fly.
Look into jmod.mapperContinuous, for instance, to know how this works…

Unless I’m wrong, this method should be more optimized than [jcom.send jcom.remote.module.to], which will send the data to each and every module’s jcom.hub… while the method above only sends it to the appropriate module…

If you are using mainly using modules of your own, you might also check 0.6 - it is fully operationnal, and begins to be thoroughly tested…. the reason why we didn’t release it yet is because not all modules are ported yet, especially the cue and mapping modules (but there is a j.cue external which does most of the job, and a general-purpose mapper model), but maybe it could be worth checking.

Hope this helps…

best,

Pascal
 

Pascal Baltazar
[hidden email]
http://www.baltazars.org

> On 08 Nov 2014, at 00:49, Eugene Cherny <[hidden email]> wrote:
>
> Thanks Trond,
>
> That was very helpful. So, the jcom.remote.module.to is the same as regular send/receive. So I guess, the same rule works when receiving messages through jcom.remote.module.from?
>
>> When you want to control many parameters in many modules in a specified sequence, you can do so by sending the messages sequentially (e.g. from the jmod.cueScript module).
>
> Yes, cue scripts are great — they are a truly lifesavers when managing state of the complex patch. But in my current patch I use jcom.send to algorithmically control a lot of modules in real-time. Maybe I introduce interaction with performer also. So the timing in this case is important.
>
> Thanks for help!
>
> Best,
> Eugene
>
> On Nov 6, 2014, at 9:05 PM, Trond Lossius <[hidden email]> wrote:
>
>> Hi Eugene,
>>
>>> I working on a big patch, which should contain a lot of little modules (about 50). I want to control those modules from some place passing messages to the [jcom.send jcom.remote.module.to] object. So my question: what happens with message when I send it through jcom.remote.module.to? Will it move from scheduler to the queue? Will the depth-first rule work?
>>
>> It will not move to any other queue, so if it is in the scheduler queue, it will stay there.
>>
>> When the message is sent to jcom.remote.module.to it will be received by the jcom.hub object in the appropriate module. This will then send it on to the appropriate jcom.parameter or jcom.message object within the module. Once the parameter value has been updated the new value is passed from the outlet of com.parameter, then from the appropriate outlet of jcom.in (or jcom.in~) and finally passed out again from the outlet of jcom.hub. Generally the idea is that each module will have a unique name, and the same goes for each of the parameters inside the module, so that there only really should be one target location for the message.
>>
>> When you want to control many parameters in many modules in a specified sequence, you can do so by sending the messages sequentially (e.g. from the jmod.cueScript module). If you have the sequence sorted correctly in the cue, the messages will be sent in the same sequence, and hence you have control of what messages are sent first and last. This is typically how I initiate my patches with many modules, e.g. in order to ensure that I have set the correct number of speakers for spatialisation before starting to describe the position of any of them.
>>
>> I hope this helps!
>>
>> Best,
>> Trond
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Jamoma-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jamoma-users
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Jamoma-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jamoma-users


------------------------------------------------------------------------------
_______________________________________________
Jamoma-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-users
Reply | Threaded
Open this post in threaded view
|

Re: jcom.remote.module.to and scheduler in 0.5.7

Evgeniy Chernyy
Thanks Pascal!

jcom.send in 0.5 is workorking as you described.

I tried to start new project with 0.6 few months ago, but the “Get current state as text” feature was not implemented at that time, so I decided to continue with 0.5.

Btw, do you have a list of unported modules somewhere? Maybe I could help with it. This is a great motivation to start using 0.6 :)

What do you think?

Best,
Eugene

On Nov 8, 2014, at 4:13 PM, Pascal Baltazar <[hidden email]> wrote:

> That’s been a while since I used 0.5, but I think you can use [jcom.send /moduleName/parameterName] to address your parameters directly… And I think they’re configurable, too… so you can change the address on the fly.
> Look into jmod.mapperContinuous, for instance, to know how this works…
>
> Unless I’m wrong, this method should be more optimized than [jcom.send jcom.remote.module.to], which will send the data to each and every module’s jcom.hub… while the method above only sends it to the appropriate module…
>
> If you are using mainly using modules of your own, you might also check 0.6 - it is fully operationnal, and begins to be thoroughly tested…. the reason why we didn’t release it yet is because not all modules are ported yet, especially the cue and mapping modules (but there is a j.cue external which does most of the job, and a general-purpose mapper model), but maybe it could be worth checking.
>
> Hope this helps…
>
> best,
>
> Pascal
>
>
> Pascal Baltazar
> [hidden email]
> http://www.baltazars.org
>
>> On 08 Nov 2014, at 00:49, Eugene Cherny <[hidden email]> wrote:
>>
>> Thanks Trond,
>>
>> That was very helpful. So, the jcom.remote.module.to is the same as regular send/receive. So I guess, the same rule works when receiving messages through jcom.remote.module.from?
>>
>>> When you want to control many parameters in many modules in a specified sequence, you can do so by sending the messages sequentially (e.g. from the jmod.cueScript module).
>>
>> Yes, cue scripts are great — they are a truly lifesavers when managing state of the complex patch. But in my current patch I use jcom.send to algorithmically control a lot of modules in real-time. Maybe I introduce interaction with performer also. So the timing in this case is important.
>>
>> Thanks for help!
>>
>> Best,
>> Eugene
>>
>> On Nov 6, 2014, at 9:05 PM, Trond Lossius <[hidden email]> wrote:
>>
>>> Hi Eugene,
>>>
>>>> I working on a big patch, which should contain a lot of little modules (about 50). I want to control those modules from some place passing messages to the [jcom.send jcom.remote.module.to] object. So my question: what happens with message when I send it through jcom.remote.module.to? Will it move from scheduler to the queue? Will the depth-first rule work?
>>>
>>> It will not move to any other queue, so if it is in the scheduler queue, it will stay there.
>>>
>>> When the message is sent to jcom.remote.module.to it will be received by the jcom.hub object in the appropriate module. This will then send it on to the appropriate jcom.parameter or jcom.message object within the module. Once the parameter value has been updated the new value is passed from the outlet of com.parameter, then from the appropriate outlet of jcom.in (or jcom.in~) and finally passed out again from the outlet of jcom.hub. Generally the idea is that each module will have a unique name, and the same goes for each of the parameters inside the module, so that there only really should be one target location for the message.
>>>
>>> When you want to control many parameters in many modules in a specified sequence, you can do so by sending the messages sequentially (e.g. from the jmod.cueScript module). If you have the sequence sorted correctly in the cue, the messages will be sent in the same sequence, and hence you have control of what messages are sent first and last. This is typically how I initiate my patches with many modules, e.g. in order to ensure that I have set the correct number of speakers for spatialisation before starting to describe the position of any of them.
>>>
>>> I hope this helps!
>>>
>>> Best,
>>> Trond
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Jamoma-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/jamoma-users
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Jamoma-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jamoma-users
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Jamoma-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jamoma-users


------------------------------------------------------------------------------
_______________________________________________
Jamoma-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-users
Reply | Threaded
Open this post in threaded view
|

Re: jcom.remote.module.to and scheduler in 0.5.7

Théo de la Hogue-2
Hi Eugene,

Le 8 nov. 2014 à 20:23, Eugene Cherny <[hidden email]> a écrit :

Thanks Pascal!

jcom.send in 0.5 is workorking as you described.

I tried to start new project with 0.6 few months ago, but the “Get current state as text” feature was not implemented at that time, so I decided to continue with 0.5.
The “Get current state as text” is alive but have been renamed "Edit current state" as the text editor allows to get and set the value of each parameter of the module.

Btw, do you have a list of unported modules somewhere? Maybe I could help with it. This is a great motivation to start using 0.6 :)

What do you think?
Sure ! any help is greatly appreciated. however I can't tell you how to retreive this list. 
Pascal or Trond should have a better picture than me of which modules needs to be ported but I can tell you there is a folder where we quarantine some modules as we didn't know if there were still interesting to have them in the standard distribution : https://github.com/jamoma/JamomaMax/tree/master/quarantined_package/patchers/models

Then here is a link to help in module porting : https://github.com/jamoma/JamomaMax/wiki/Porting-modules-to-0.6

Best,
TO



Best,
Eugene

On Nov 8, 2014, at 4:13 PM, Pascal Baltazar <[hidden email]> wrote:

That’s been a while since I used 0.5, but I think you can use [jcom.send /moduleName/parameterName] to address your parameters directly… And I think they’re configurable, too… so you can change the address on the fly.
Look into jmod.mapperContinuous, for instance, to know how this works…

Unless I’m wrong, this method should be more optimized than [jcom.send jcom.remote.module.to], which will send the data to each and every module’s jcom.hub… while the method above only sends it to the appropriate module…

If you are using mainly using modules of your own, you might also check 0.6 - it is fully operationnal, and begins to be thoroughly tested…. the reason why we didn’t release it yet is because not all modules are ported yet, especially the cue and mapping modules (but there is a j.cue external which does most of the job, and a general-purpose mapper model), but maybe it could be worth checking.

Hope this helps…

best,

Pascal


Pascal Baltazar
[hidden email]
http://www.baltazars.org

On 08 Nov 2014, at 00:49, Eugene Cherny <[hidden email]> wrote:

Thanks Trond,

That was very helpful. So, the jcom.remote.module.to is the same as regular send/receive. So I guess, the same rule works when receiving messages through jcom.remote.module.from?

When you want to control many parameters in many modules in a specified sequence, you can do so by sending the messages sequentially (e.g. from the jmod.cueScript module).

Yes, cue scripts are great — they are a truly lifesavers when managing state of the complex patch. But in my current patch I use jcom.send to algorithmically control a lot of modules in real-time. Maybe I introduce interaction with performer also. So the timing in this case is important.

Thanks for help!

Best,
Eugene

On Nov 6, 2014, at 9:05 PM, Trond Lossius <[hidden email]> wrote:

Hi Eugene,

I working on a big patch, which should contain a lot of little modules (about 50). I want to control those modules from some place passing messages to the [jcom.send jcom.remote.module.to] object. So my question: what happens with message when I send it through jcom.remote.module.to? Will it move from scheduler to the queue? Will the depth-first rule work?

It will not move to any other queue, so if it is in the scheduler queue, it will stay there.

When the message is sent to jcom.remote.module.to it will be received by the jcom.hub object in the appropriate module. This will then send it on to the appropriate jcom.parameter or jcom.message object within the module. Once the parameter value has been updated the new value is passed from the outlet of com.parameter, then from the appropriate outlet of jcom.in (or jcom.in~) and finally passed out again from the outlet of jcom.hub. Generally the idea is that each module will have a unique name, and the same goes for each of the parameters inside the module, so that there only really should be one target location for the message.

When you want to control many parameters in many modules in a specified sequence, you can do so by sending the messages sequentially (e.g. from the jmod.cueScript module). If you have the sequence sorted correctly in the cue, the messages will be sent in the same sequence, and hence you have control of what messages are sent first and last. This is typically how I initiate my patches with many modules, e.g. in order to ensure that I have set the correct number of speakers for spatialisation before starting to describe the position of any of them.

I hope this helps!

Best,
Trond
------------------------------------------------------------------------------
_______________________________________________
Jamoma-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-users


------------------------------------------------------------------------------
_______________________________________________
Jamoma-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-users


------------------------------------------------------------------------------
_______________________________________________
Jamoma-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-users


------------------------------------------------------------------------------
_______________________________________________
Jamoma-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-users


------------------------------------------------------------------------------

_______________________________________________
Jamoma-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-users