<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi, here is the liveOSC API :
<a class="moz-txt-link-freetext" href="https://github.com/hanshuebner/LiveOSC/blob/master/OSCAPI.txt">https://github.com/hanshuebner/LiveOSC/blob/master/OSCAPI.txt</a><br>
It's a remotescript for Ableton Live and you can see how it's done
here.<br>
cheers<br>
Dirk<br>
<br>
Am 03.12.2015 um 18:11 schrieb William Huston:<br>
</div>
<blockquote
cite="mid:CAOTwkqDN_HqrGkDr56UJUspdD1Nt_23xdm0TsD5GnCTT04z9NA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>How many people are using OSC for automation, and/or
persistence (store/recall)? <br>
<br>
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 <br>
<br>
</div>
<div>/Instrument/Component/SubComponent/Parameter <br>
</div>
<div><br>
</div>
<div>But once this is done, network control is easy. <br>
</div>
<div><br>
</div>
<u><b>Basic Address Space questions<br>
</b></u></div>
<div>
<div><br>
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. <br>
<br>
So does it make sense to have my address space look like
this:<br>
<br>
<div style="margin-left:40px">/Screech/MultiOsc*/Sine =
0.5 # sets this parameter in all instances <br>
/Screech/MultiOsc1/Freq = 110 <br>
/Screech/MultiOsc2/Freq = 220 <br>
/Screech/MultiOsc3/Freq = 440<br>
/Screech/MultiOsc4/Freq = 0<br>
</div>
...etc...<br>
<br>
Or should I make each instance of MultiOsc addressable
like this:<br>
<br>
<div style="margin-left:40px">/Screech/MultiOsc/*/Sine =
0.5 <br>
/Screech/MultiOsc/1/Freq = 110 <br>
/Screech/MultiOsc/2/Freq = 220 <br>
/Screech/MultiOsc/3/Freq = 440<br>
</div>
<br>
</div>
<u><b>OSC for Persistance (SAVE/RECALL of patch settings)<br>
</b></u></div>
<div><br>
</div>
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. <br>
<br>
</div>
<div>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. <br>
<br>
</div>
<div>(I am only stating this because I notice that some people
build instruments from the basic elements each time)<br>
</div>
<div><br>
I want to develop a library of abstractions which <i><b>have
persistence built in</b></i>, so that when I build an
instrument with these abstractions, Save/Recall is also built
in.<br>
</div>
<div>
<div>
<div>
<div><br>
</div>
<div>I am trying to imagine how this would work....???<br>
</div>
<div><br>
</div>
<div>My idea is that after I assemble a patch built with
my OSC-enabled abstractions, I can issue a global
command like:<br>
<br>
</div>
<div>
<div style="margin-left:40px">/Screech/CONTROL/Show<br>
</div>
<br>
</div>
<div>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". <br>
<br>
</div>
<div>Each OSC-enabled abstraction which would receive a
/Show command, and query the state of every OSC-setable
parameter, and report back (how?).<br>
<br>
</div>
<div>Management module CONTROL then can take these
settings and write to a file, which can then be
recalled....<br>
<br>
</div>
<div>I really don't know what I'm doing here, just
thinking out loud.<br>
</div>
<div>Has anyone already done anything like this??<br>
</div>
<div><br>
</div>
<div><u><b>GOAL=PD Interoperability Standard<br>
</b></u></div>
<div><br>
</div>
<div>My ultimate goal is to develop an interoperability
standard for <br>
OSC-enabled PD modules which can then be shared, which
have both automation (remote control) and persistence
(store/recall) integrated. </div>
<div><br>
</div>
<br>
<div>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 <b>built-in
Automation and Persistence using OSC</b>, and how
these might be addressed in a higher level patch. <br>
<br>
</div>
<div>THANKS!<br>
</div>
<div>BH<br>
</div>
<div><br>
<br clear="all">
<br>
-- <br>
<div class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">--<br>
May you, and all beings<br>
be happy and free from suffering :)<br>
-- ancient Buddhist Prayer (Metta)<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
<br>
</body>
</html>