SC: Conveying Envelope descriptions via OSC bundles.

[x0ph]

Hi everyone,
Actually I got a couple of questions. I'd like to pass Env parameters as args to a Synth from a custom application using OSC. I found one way to modify Env parameters in a synth is to use control.names in the SynthDef (this is from the SChelpBook [Help->Control->Env]), e.g.

[dewdrop_world]

If you can get the sources from svn and build the latest version, this whole thing got a lot easier just recently. In the newest code, it should be OK to do this:

Synth("Help-Env-newClear", [t_gate: 1, env: e.asArray]);

In the stable 3.2 version, the setn technique is still needed.

[x0ph]

Thanks dewdrop_world !

Your comments actually helped a lot. It’s kind of working now!
Now I got stuck at another point.
I try to set up an additive synth that mixes n number of (not necessarily harmonic) frequencies together, each with individual ADSR envelope.
I've decided to use a simple sine synth with control.names for the \env (as mentioned above) to create the group of sines with the desired timbre. That works pretty good so far, I can define master controls that influence every group member.
The problem is, that I'd like to play this newly created sound like an instrument - and I don't want to send a whole bunch of envelope definitions and frequencies each time I play a simple note! So my question is, whether there's a way to reuse the configuration of such a group with little changes, for instance only the frequency changes. That is I want to re-trigger the group of synths.

Instr sounded somewhat like what I'm looking for, but I didn't quite get the idea behind Instr. All I could figure out is that "An Instr is not a SynthDef". So what is it
Also: Is there a smart way of integrating pitch shifts in additive synths (each partial with a factor)

[x0ph]

Does anyone know the types (integer, float, binary, ...) SuperCollider uses for envelope osc descriptions such as

[dewdrop_world]

If you send them to controls that are local to a synth, once the synth goes away, the values you sent are forgotten. So maybe it would be better to send them to something else.

Maybe a buffer... instead of using the array control, access the buffer data using Index.kr(bufnum, (0..(buffersize)). Once you put the data into a buffer, they persist there until you put something else in.

I think Instr is probably not what you want here. An Instr is a prototype, like a cookie cutter that can make lots of slightly varying SynthDefs. But if you pass an Env in at the time of building the SynthDef, the Env is hardcoded and can't be changed from outside.

[dewdrop_world]

Maybe it would help to clarify that all those type tags are i because all the numbers in the message array are integers. If some of them were floats, there would be f's in those slots.

Also, I found out what was up with asRawOSC. If the array starts with a number, it assumes that it's an OSC bundle rather than a single message.

[ 9, \default, 1000, 0, 1, \freq, 600, \amp, 0.1 ].asRawOSC
--> Int8Array[ 35, 98, 117, 110, 100, 108, 101, 0, 0, 0, 0, 9, 0, 0, 0, 0 ]

That is, it writes out the header for #bundle with nine messages enclosed, but then it doesn't know how to interpret the non-array elements following. But a one-command bundle gets written out properly.

[ 1, [9, \default, 1000, 0, 1, \freq, 600, \amp, 0.1] ].asRawOSC

Int8Array[ 35, 98, 117, 110, 100, 108, 101, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 56, 0, 0, 0, 9, 44, 115, 105, 105, 105, 115, 105, 115, 102, 0, 0, 0, 100, 101, 102, 97, 117, 108, 116, 0, 0, 0, 3, -24, 0, 0, 0, 0, 0, 0, 0, 1, 102, 114, 101, 113, 0, 0, 0, 0, 0, 0, 2, 88, 97, 109, 112, 0, 61, -52, -52, -51 ]

James

[dewdrop_world]

Actually, even better might be to use control buses for the envelopes. Control buses also persist past the lifetime of any single synth.

That is, if the envelope array size is 20:

[x0ph]

I changed my set-up now to work with control busses, though I had to hard code them, since I can't take advantage of the SC internal bus.control (this would require me to send the index number to my external GUI application, and I don't want to implement a bidirectional OSC yet).
This actually solved the problem of envelopes stopping before the release node! Good hint.

[dewdrop_world]