[PD] Getting off the ground with OSC

[dirkx]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151204/8fc99abc/attachment-0001.html>