How many people are using OSC for automation, and/or persistence (store/recall)?
I'm trying to establish a standard for automation of my own library of modules (abstractions). Note that I have no plans at the moment for using OSC for network remote control. I only want to use the OSC hierarchical way of addressing components, like
/Instrument/Component/SubComponent/Parameter
But once this is done, network control is easy.
*Basic Address Space questions*
Like, let's say I have an instrument called Screech. Inside, there are 4 MultiOsc modules 1-4. Each MultiOsc has several things which can be set, like Sine, Saw, PWM, Noise, etc.
So does it make sense to have my address space look like this:
/Screech/MultiOsc*/Sine = 0.5 # sets this parameter in all instances /Screech/MultiOsc1/Freq = 110 /Screech/MultiOsc2/Freq = 220 /Screech/MultiOsc3/Freq = 440 /Screech/MultiOsc4/Freq = 0 ...etc...
Or should I make each instance of MultiOsc addressable like this:
/Screech/MultiOsc/*/Sine = 0.5 /Screech/MultiOsc/1/Freq = 110 /Screech/MultiOsc/2/Freq = 220 /Screech/MultiOsc/3/Freq = 440
*OSC for Persistance (SAVE/RECALL of patch settings)*
One thing that frustrates me is when I build a large and wonderful patch, and find some settings I like, when I exit PD all those settings are lost.
My style of building instruments is to build patches from a library of small modules (abstractions) as building blocks which I string together to make high-level instruments.
(I am only stating this because I notice that some people build instruments from the basic elements each time)
I want to develop a library of abstractions which *have persistence built in*, so that when I build an instrument with these abstractions, Save/Recall is also built in.
I am trying to imagine how this would work....???
My idea is that after I assemble a patch built with my OSC-enabled abstractions, I can issue a global command like:
/Screech/CONTROL/Show
This command would be routed to instrument Screech, to a special management module called CONTROL which would query each OSC-enabled abstraction within the patch and say "Tell me your present state".
Each OSC-enabled abstraction which would receive a /Show command, and query the state of every OSC-setable parameter, and report back (how?).
Management module CONTROL then can take these settings and write to a file, which can then be recalled....
I really don't know what I'm doing here, just thinking out loud. Has anyone already done anything like this??
*GOAL=PD Interoperability Standard*
My ultimate goal is to develop an interoperability standard for OSC-enabled PD modules which can then be shared, which have both automation (remote control) and persistence (store/recall) integrated.
Anyway-- I'm quite new to OSC... So I would love to hear/see some *high-level* descriptions of how people are using OSC with PD (block diagrams, or design documents), and/or your general thoughts about how to create a library of abstractions which have *built-in Automation and Persistence using OSC*, and how these might be addressed in a higher level patch.
THANKS! BH
Not OSC, but for persistence I've usually stored control values in an array and saved the contents of that array. You can also use textfiles or even qlists if you need to store more than numbers.
On Fri, Dec 4, 2015 at 2:11 AM, William Huston williamahuston@gmail.com wrote:
So does it make sense to have my address space look like this:
/Screech/MultiOsc*/Sine = 0.5 # sets this parameter in all instances /Screech/MultiOsc1/Freq = 110 /Screech/MultiOsc2/Freq = 220 /Screech/MultiOsc3/Freq = 440 /Screech/MultiOsc4/Freq = 0 ...etc...
Or should I make each instance of MultiOsc addressable like this:
/Screech/MultiOsc/*/Sine = 0.5 /Screech/MultiOsc/1/Freq = 110 /Screech/MultiOsc/2/Freq = 220 /Screech/MultiOsc/3/Freq = 440
For me the SooperLooper OSC implementation seems quite well-thought out. Ardour also has quite a thorough and robust implementation. Although they are not PD, you may want to look at these applications for some guidance. Both use the latter method (although omit the equals sign) which seems far easier when routing and so on. Rather than asterisk, SooperLooper uses 0 for all loops, which is something you might consider as well...
On Fri, Dec 4, 2015 at 11:35 AM, michael noble looplog@gmail.com wrote:
Rather than asterisk, SooperLooper uses 0 for all loops
Apologies, SooperLooper uses -1 to address all loops. But its an integer nonetheless...
Thanks Michael. If others are following along, I'm just posting the link to SL's OSC implementation.
(This app looks exciting to play with apart from the OSC discussion!)
http://essej.net/sooperlooper/doc_osc.html
On Thu, Dec 3, 2015 at 9:35 PM, michael noble looplog@gmail.com wrote:
On Fri, Dec 4, 2015 at 2:11 AM, William Huston williamahuston@gmail.com wrote:
So does it make sense to have my address space look like this:
/Screech/MultiOsc*/Sine = 0.5 # sets this parameter in all instances /Screech/MultiOsc1/Freq = 110 /Screech/MultiOsc2/Freq = 220 /Screech/MultiOsc3/Freq = 440 /Screech/MultiOsc4/Freq = 0 ...etc...
Or should I make each instance of MultiOsc addressable like this:
/Screech/MultiOsc/*/Sine = 0.5 /Screech/MultiOsc/1/Freq = 110 /Screech/MultiOsc/2/Freq = 220 /Screech/MultiOsc/3/Freq = 440
For me the SooperLooper OSC implementation seems quite well-thought out. Ardour also has quite a thorough and robust implementation. Although they are not PD, you may want to look at these applications for some guidance. Both use the latter method (although omit the equals sign) which seems far easier when routing and so on. Rather than asterisk, SooperLooper uses 0 for all loops, which is something you might consider as well...
Hi, here is the liveOSC API : https://github.com/hanshuebner/LiveOSC/blob/master/OSCAPI.txt It's a remotescript for Ableton Live and you can see how it's done here. cheers Dirk
Am 03.12.2015 um 18:11 schrieb William Huston:
How many people are using OSC for automation, and/or persistence (store/recall)?
I'm trying to establish a standard for automation of my own library of modules (abstractions). Note that I have no plans at the moment for using OSC for network remote control. I only want to use the OSC hierarchical way of addressing components, like
/Instrument/Component/SubComponent/Parameter
But once this is done, network control is easy.
_*Basic Address Space questions *_
Like, let's say I have an instrument called Screech. Inside, there are 4 MultiOsc modules 1-4. Each MultiOsc has several things which can be set, like Sine, Saw, PWM, Noise, etc.
So does it make sense to have my address space look like this:
/Screech/MultiOsc*/Sine = 0.5 # sets this parameter in all instances /Screech/MultiOsc1/Freq = 110 /Screech/MultiOsc2/Freq = 220 /Screech/MultiOsc3/Freq = 440 /Screech/MultiOsc4/Freq = 0 ...etc...
Or should I make each instance of MultiOsc addressable like this:
/Screech/MultiOsc/*/Sine = 0.5 /Screech/MultiOsc/1/Freq = 110 /Screech/MultiOsc/2/Freq = 220 /Screech/MultiOsc/3/Freq = 440
_*OSC for Persistance (SAVE/RECALL of patch settings) *_
One thing that frustrates me is when I build a large and wonderful patch, and find some settings I like, when I exit PD all those settings are lost.
My style of building instruments is to build patches from a library of small modules (abstractions) as building blocks which I string together to make high-level instruments.
(I am only stating this because I notice that some people build instruments from the basic elements each time)
I want to develop a library of abstractions which /*have persistence built in*/, so that when I build an instrument with these abstractions, Save/Recall is also built in.
I am trying to imagine how this would work....???
My idea is that after I assemble a patch built with my OSC-enabled abstractions, I can issue a global command like:
/Screech/CONTROL/Show
This command would be routed to instrument Screech, to a special management module called CONTROL which would query each OSC-enabled abstraction within the patch and say "Tell me your present state".
Each OSC-enabled abstraction which would receive a /Show command, and query the state of every OSC-setable parameter, and report back (how?).
Management module CONTROL then can take these settings and write to a file, which can then be recalled....
I really don't know what I'm doing here, just thinking out loud. Has anyone already done anything like this??
_*GOAL=PD Interoperability Standard *_
My ultimate goal is to develop an interoperability standard for OSC-enabled PD modules which can then be shared, which have both automation (remote control) and persistence (store/recall) integrated.
Anyway-- I'm quite new to OSC... So I would love to hear/see some *high-level* descriptions of how people are using OSC with PD (block diagrams, or design documents), and/or your general thoughts about how to create a library of abstractions which have *built-in Automation and Persistence using OSC*, and how these might be addressed in a higher level patch.
THANKS! BH
--
May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hey William
netpd does a lot already of what you describe. It's used for both, syncing between clients, but also for saving and restoring presets.
The design of netpd is quite similar to your proposal. Instruments are assigned a numeric id so that they can be treated separately when storing or dumping a state. So we have instrument name spaces:
/1/mysynth /2/othersynth /3/mysynth
Each parameter of an instruments is managed by a data container abstractions. The simplest case would be a single numeric value:
[netpd_f $1 freq 440]
The $1 is the id of the instrument and 'freq' is the parameter name. The abstraction dumps the value with the correct OSC address on request and also listens on any changes for the given address. The full OSC address of above example parameter would be (inside first instance of mysynth):
/1/mysynth/freq 440
Assume you have submodule that you use in many instruments. In your instrument you would instantiate it as [mymodule $1 instancename]. Inside that submodule you may have data containers as described above. Those would be instantiated like this:
[netpd_f $1 $2/freq 440]
The OSC address of a parameter inside the instrument's submodule would then be:
/1/mysynth/instancename/freq 440
You can nest that as deep as you want. Then things are possible to address all freq parameters in each of the submodules with
/1/mysynth/*/freq
Now, in order to retrieve the whole state of your instrument, each instrument has exactly one instance of [netpd_head], which is kind of the state manager of the instrument:
[netpd_head $1 mysynth]
(This assumes that you load your instrument as an abstraction and give it a unique id as argument, like [mysynth 1])
This abstraction listens on the address:
/1/mysynth/dump/request
And triggers a dump of all parameters in the instrument (including all submodules and sub-submodules) so that they send their current state each with the correct address.
I'd be very glad if we could work together on this, rather than you and me work on separate frameworks. My reasoning is that I'd love to use your instruments in netpd ;-)
Roman
On Thu, 2015-12-03 at 12:11 -0500, William Huston wrote:
How many people are using OSC for automation, and/or persistence (store/recall)?
I'm trying to establish a standard for automation of my own library of modules (abstractions). Note that I have no plans at the moment for using OSC for network remote control. I only want to use the OSC hierarchical way of addressing components, like
/Instrument/Component/SubComponent/Parameter
But once this is done, network control is easy.
Basic Address Space questions
Like, let's say I have an instrument called Screech. Inside, there are 4 MultiOsc modules 1-4. Each MultiOsc has several things which can be set, like Sine, Saw, PWM, Noise, etc.
So does it make sense to have my address space look like this:
/Screech/MultiOsc*/Sine = 0.5 # sets this parameter in all instances /Screech/MultiOsc1/Freq = 110 /Screech/MultiOsc2/Freq = 220 /Screech/MultiOsc3/Freq = 440 /Screech/MultiOsc4/Freq = 0
...etc...
Or should I make each instance of MultiOsc addressable like this:
/Screech/MultiOsc/*/Sine = 0.5 /Screech/MultiOsc/1/Freq = 110 /Screech/MultiOsc/2/Freq = 220 /Screech/MultiOsc/3/Freq = 440
OSC for Persistance (SAVE/RECALL of patch settings)
One thing that frustrates me is when I build a large and wonderful patch, and find some settings I like, when I exit PD all those settings are lost.
My style of building instruments is to build patches from a library of small modules (abstractions) as building blocks which I string together to make high-level instruments.
(I am only stating this because I notice that some people build instruments from the basic elements each time)
I want to develop a library of abstractions which have persistence built in, so that when I build an instrument with these abstractions, Save/Recall is also built in.
I am trying to imagine how this would work....???
My idea is that after I assemble a patch built with my OSC-enabled abstractions, I can issue a global command like:
/Screech/CONTROL/Show
This command would be routed to instrument Screech, to a special management module called CONTROL which would query each OSC-enabled abstraction within the patch and say "Tell me your present state".
Each OSC-enabled abstraction which would receive a /Show command, and query the state of every OSC-setable parameter, and report back (how?).
Management module CONTROL then can take these settings and write to a file, which can then be recalled....
I really don't know what I'm doing here, just thinking out loud.
Has anyone already done anything like this??
GOAL=PD Interoperability Standard
My ultimate goal is to develop an interoperability standard for OSC-enabled PD modules which can then be shared, which have both automation (remote control) and persistence (store/recall) integrated.
Anyway-- I'm quite new to OSC... So I would love to hear/see some *high-level* descriptions of how people are using OSC with PD (block diagrams, or design documents), and/or your general thoughts about how to create a library of abstractions which have built-in Automation and Persistence using OSC, and how these might be addressed in a higher level patch.
THANKS!
BH
--
May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thank you Roman!
I very much appreciate this, and also your prior invitation to participate in NetPD jams.
I hadn't realized that you'd already solved many of these problems.
I'll be in touch off-list. I am very excited about collaboration. :)
On Friday, December 4, 2015, Roman Haefeli reduzent@gmail.com wrote:
Hey William
netpd does a lot already of what you describe. It's used for both, syncing between clients, but also for saving and restoring presets.
The design of netpd is quite similar to your proposal. Instruments are assigned a numeric id so that they can be treated separately when storing or dumping a state. So we have instrument name spaces:
/1/mysynth /2/othersynth /3/mysynth
Each parameter of an instruments is managed by a data container abstractions. The simplest case would be a single numeric value:
[netpd_f $1 freq 440]
The $1 is the id of the instrument and 'freq' is the parameter name. The abstraction dumps the value with the correct OSC address on request and also listens on any changes for the given address. The full OSC address of above example parameter would be (inside first instance of mysynth):
/1/mysynth/freq 440
Assume you have submodule that you use in many instruments. In your instrument you would instantiate it as [mymodule $1 instancename]. Inside that submodule you may have data containers as described above. Those would be instantiated like this:
[netpd_f $1 $2/freq 440]
The OSC address of a parameter inside the instrument's submodule would then be:
/1/mysynth/instancename/freq 440
You can nest that as deep as you want. Then things are possible to address all freq parameters in each of the submodules with
/1/mysynth/*/freq
Now, in order to retrieve the whole state of your instrument, each instrument has exactly one instance of [netpd_head], which is kind of the state manager of the instrument:
[netpd_head $1 mysynth]
(This assumes that you load your instrument as an abstraction and give it a unique id as argument, like [mysynth 1])
This abstraction listens on the address:
/1/mysynth/dump/request
And triggers a dump of all parameters in the instrument (including all submodules and sub-submodules) so that they send their current state each with the correct address.
I'd be very glad if we could work together on this, rather than you and me work on separate frameworks. My reasoning is that I'd love to use your instruments in netpd ;-)
Roman
On Thu, 2015-12-03 at 12:11 -0500, William Huston wrote:
How many people are using OSC for automation, and/or persistence (store/recall)?
I'm trying to establish a standard for automation of my own library of modules (abstractions). Note that I have no plans at the moment for using OSC for network remote control. I only want to use the OSC hierarchical way of addressing components, like
/Instrument/Component/SubComponent/Parameter
But once this is done, network control is easy.
Basic Address Space questions
Like, let's say I have an instrument called Screech. Inside, there are 4 MultiOsc modules 1-4. Each MultiOsc has several things which can be set, like Sine, Saw, PWM, Noise, etc.
So does it make sense to have my address space look like this:
/Screech/MultiOsc*/Sine = 0.5 # sets this parameter in all instances /Screech/MultiOsc1/Freq = 110 /Screech/MultiOsc2/Freq = 220 /Screech/MultiOsc3/Freq = 440 /Screech/MultiOsc4/Freq = 0
...etc...
Or should I make each instance of MultiOsc addressable like this:
/Screech/MultiOsc/*/Sine = 0.5 /Screech/MultiOsc/1/Freq = 110 /Screech/MultiOsc/2/Freq = 220 /Screech/MultiOsc/3/Freq = 440
OSC for Persistance (SAVE/RECALL of patch settings)
One thing that frustrates me is when I build a large and wonderful patch, and find some settings I like, when I exit PD all those settings are lost.
My style of building instruments is to build patches from a library of small modules (abstractions) as building blocks which I string together to make high-level instruments.
(I am only stating this because I notice that some people build instruments from the basic elements each time)
I want to develop a library of abstractions which have persistence built in, so that when I build an instrument with these abstractions, Save/Recall is also built in.
I am trying to imagine how this would work....???
My idea is that after I assemble a patch built with my OSC-enabled abstractions, I can issue a global command like:
/Screech/CONTROL/Show
This command would be routed to instrument Screech, to a special management module called CONTROL which would query each OSC-enabled abstraction within the patch and say "Tell me your present state".
Each OSC-enabled abstraction which would receive a /Show command, and query the state of every OSC-setable parameter, and report back (how?).
Management module CONTROL then can take these settings and write to a file, which can then be recalled....
I really don't know what I'm doing here, just thinking out loud.
Has anyone already done anything like this??
GOAL=PD Interoperability Standard
My ultimate goal is to develop an interoperability standard for OSC-enabled PD modules which can then be shared, which have both automation (remote control) and persistence (store/recall) integrated.
Anyway-- I'm quite new to OSC... So I would love to hear/see some *high-level* descriptions of how people are using OSC with PD (block diagrams, or design documents), and/or your general thoughts about how to create a library of abstractions which have built-in Automation and Persistence using OSC, and how these might be addressed in a higher level patch.
THANKS!
BH
--
May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-
dirkx -
Matt Barber -
michael noble -
Roman Haefeli -
William Huston