[PD] Getting off the ground with OSC

[William Huston]

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

-- 
--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151204/a2f11b89/attachment.html>