[PD] Getting off the ground with OSC

[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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151203/0441b129/attachment.html>