Updated csoundm to use the register facility .

[gogins]

I'm trying this pull request again. If you don't want this just say so.

The logic you had for using an external instance of Csound was not suited to my use cases, and would have failed in use. The external Csound will, usually, already have compiled an external orchestra and be running, so the csound.mjs module should not call compile or start on an external instance of Csound.

I updated the csoundm function to use the new 'register' function for Patterns. I also updated csoundm to convey the Strudel signals in the same way as the existing csound function.

[felixroos]

I'll merge this now, though it might make more sense to find a less specific abstraction in the future, making this one obsolete, as outlined in #283 (comment) . also, a solution for key value mappings is still missing, as described here #270 (comment) , an alternative implementation might use channels with unique names.

[gogins]

I am re-examining your comments, and trying to envision what your use cases are. More later. Best, Mike

…

----------------------------------------------------- Michael Gogins Irreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com

On Tue, Dec 13, 2022 at 4:07 PM Felix Roos ***@***.***> wrote: I'll merge this now, though it might make more sense to find a less specific abstraction in the future, making this one obsolete, as outlined in #283 (comment) <#283 (comment)> . also, a solution for key value mappings is still missing, as described here #270 (comment) <#270 (comment)> , an alternative implementation might use channels with unique names. — Reply to this email directly, view it on GitHub <#303 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQIGJM63NNU64GFTABNTITWNDQRDANCNFSM6AAAAAAS4UTQLU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[gogins]

The next version of Csound, 7, will have proper dictionaries. Until then, something like this might work for sending the signals currently encoded as an OSC like string. First, understand that a fractional instrument number can be used as a note ID, e.g. to tie later notes to earlier ones; notes with the same ID can be identified and tied in the instrument code. But the fractional number can be used both with string names and with instrument numbers. The following assumes that the value of a signal can be different for different notes, even different notes of the same instrument. If that's not the case, just leave out "note ID." There would be a naming convention for defining Csound channel names to carry Strudel signals. First the name (or number) of the instrument, e.g. 'CoolSynth' or 'i1', then a note ID that would have to be created in Strudel, e.g. 'CoolSynth.1', then the name of the Strudel signal, e.g. "cutoff." The Csound output code would then be something like this: _csound.setChannelValue('CoolSynth.1.cutoff', value); In the instrument definition, at initialization time (i.e. only once during a note), the instrument would parse out its name and the note ID and append the signal name, to read the value: S_instrument_name nstrstr p1 i_note_id = frac(p1) S_signal_name sprintf "%s.%f.cutoff", S_instrument_name, i_note_id k_cutoff_value chnget S_signal_name This of course can be put into a user-defined opcode so all you need to pass is the signal name: value getSignal "cutoff" Also there are array forms of the chnget opcodes, e.g. chngetk, so you can query any number of named channels at the same time. Finally, the Csound channels can carry audio signals as well as control signals. Best, Michael Gogins Irreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com On Tue, Dec 13, 2022 at 8:08 PM Michael Gogins ***@***.***> wrote:

…

I am re-examining your comments, and trying to envision what your use cases are. More later. Best, Mike ----------------------------------------------------- Michael Gogins Irreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com On Tue, Dec 13, 2022 at 4:07 PM Felix Roos ***@***.***> wrote: > I'll merge this now, though it might make more sense to find a less > specific abstraction in the future, making this one obsolete, as outlined > in #283 (comment) > <#283 (comment)> > . also, a solution for key value mappings is still missing, as described > here #270 (comment) > <#270 (comment)> > , an alternative implementation might use channels with unique names. > > — > Reply to this email directly, view it on GitHub > <#303 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABQIGJM63NNU64GFTABNTITWNDQRDANCNFSM6AAAAAAS4UTQLU> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >