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