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 > >
--
--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)