How to construct Kyma-fied OSC syntax using 'variable' names?

Question

Referring to this part of the related Q&A:

For example, in the Sound being replicated, you could do something like:

(!osc_count ge: ?VoiceNumber) true: !osc_value false: 0

to provide a default value (or to turn off the output of a Sound) when too few values were supplied.

Could I construct the hot value !osc_value with a user-supplied string in the place of 'value', by using the asHotValue command/technique as outlined on p.220 of "Kyma X Revealed!"?

For example, create a function (i.e. myFaderMaker) that constructs a hot value based on a supplied string that's available pre-compilation, and store the result of a call to that in a variable, which is then supplied to the above example code, in place of !osc_value.

Something like this:

| myFaderMaker oscValue |

myFaderMaker := [:str | ('osc_', str) asHotValue].

oscValue := myFaderMaker value: myArbitraryOSCAddress

 

then, in the sound being replicated, do something like:

(!osc_count ge: ?VoiceNumber) true: oscValue false: 0

...as long as oscValue is still in scope!

Next, in a SoundToGlobalController external to the replicator, assign incoming consecutive osc-values to an EventVariable array, and output the entire array as the GeneratedEvent (which could then be used to directly populate a sequencer field with values, for example):

| anArray, myFaderMaker2 |

myFaderMaker2 := [:str :num | ('osc_', str, '__', (num printString)) asHotValue].

anArray := EventVariable new size: oscCountMaxValue.

1 to: oscCountMaxValue do: [ :i |

    (anArray @< i) <+ (myFaderMaker2 value: myArbitraryOSCAddress value: i) ].

"replace this line with an expression that truncates anArray to the size of !osc_count ??"

anArray.

 

This inspires a few related questions:

[1] In the above code example: 

Is there a way to, at the Capytalk update rate (necessarily), truncate anArray to the size of !osc_count, or similarly, copy those values to a new array?  If so, could a version of this example be made without use of the replicator, by referring to the osc hotValues directly using an approach like in 'myFaderMaker2' above... provided that the resulting array count does not exceed !osc_count, or otherwise could somehow be made to "stop" at that hotValue-supplied index value?

[2] Where might one best place a 'mini-code-library' of predefined blocks, to make them available to the rest of the sound?

I have some more questions mulling around my brain, but these are the basics that should lead me to figure the rest out on my own. Thank you!

 

Comments

A Script can do the same kinds of things a Replicator can. If you've got a Sound in the input of a Script called "mySound" you can do something like this in the Script:


    (1 to: 10) do: [:i |
        mySound start: 0 s soundNumber: i oscName: ('myName' & i) asHotValue ].


That will create 10 copies of "mySound", starting them all simultaneously at start-up. (I haven't got Kyma turned on right now so I think that should be right, or something very similar).

and then in your Sound you can put the ?soundNumber and ?osc_name variables:

    (!osc_count ge: ?soundNumber) true: ?osc_name false: 0

---

Hi Thom,
Could you please describe the end-result/behavior you are after? Do you want to populate the Array fields of a StepSequencer? We have a feeling there *may* be a different approach, but we need to understand what your end goal is first.
Thanks for your help!

---

Yes, that's what I'm looking to do right now, and then after that start populating other values/fields via OSC.  

I got it working by setting EndIndex in the Sequencer to the received !osc_count, though now there's some new questions pertaining to how the VCS interacts with the incoming OSC values.  I want to attach an example of my sound so I'm opening a new question related to this.

BTW, does the different approach you mentioned feature use of the "MIDI voice from Script" object? Because I remember seeing somewhere in the documentation that it may be preferred above other approaches when working with note-level events.  I haven't tried that yet, since I'm much more drawn to using a Sequencer-based approach, to be able to mix values coming from OSC with other sources being generated live within the sound.. although I haven't gotten to that yet so I'm not sure yet what the difference might be.

This reminds me, I also remember seeing somewhere awhile back, some mention of using the Step Sequencer as a data-structure, for a way to set and maintain arrays of values for use elsewhere within a sound.. just as a way of thinking about its possible uses, not as another differently-functioning mode or anything like that.. I'm not sure if there's anything to be gained with this kind of mindset.

---

You could create an "array" of EventValues (HotValues) using a collect: statement:

    (1 to: 8) collect: [:i| !myHotValue suffix: i]

It's not really an "array" but you could use those EventValues as a kind of data structure. You could put that expression in any number of Sounds and then anything that set any of the values (like OSC or a STGC) would be received by all Sounds that contain that expression.

I don't think you'd need a StepSequencer to do that. The StepSequencer adds the functionality of rhythmically stepping through the values but you don't need that if you're just using it as a data structure.

---

I've often used "collect:" for writing similar kinds of expressions within a script, while not seeing the simplicity of using a much more direct approach like you've suggested.

Thanks for the clarification.. it increased my understanding of the manner and value in a more direct approach