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)
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
