[PD] Getting off the ground with OSC

[Roman Haefeli]

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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151204/c94d365d/attachment-0001.sig>