First time here? Check out the FAQ!
x

Sending integer data to Kyma in real-time

+1 vote
503 views
I'm running a python program which creates an array of data I want to send to kyma in real-time.

I've assumed that OSC would be the way to go for this, but I'd welcome other / better ideas.

I'm trying to send an array of around 50 to 100 integer values. Currently each value is in the range of 1 - 127.  I have been able to control VCS widgets by sending floats in the range of 0 - 1, but ideally want to send an array of integers straight into an array or some kind of data structure in kyma.

Am I limited to sending floats between 0 - 1 over OSC?

Is there something easier or more obvious I should be doing?

 

Thanks!
asked Jun 21, 2016 in Controllers, OSC & MIDI by alan-jackson (Virtuoso) (15,840 points)
I have now discovered that I don't need to scale the numbers to between 0 - 1. If I just turn the numbers into floats that seems to work - at least while a VCS fader maxes out at 1.0 it's happy enough to show a value of 48.0 in its value label.

I've been using:
!osc_mynumberlist__1
!osc_mynumberlist__2
...

in a bunch of constant sounds to get the numbers out of the array I'm sending. Which of course creates VCS widgets and has been helpful to see the data arriving but ultimately I don't want widgets and I don't want to create 100 constant sounds. I'm assuming I'll need to suck in the OSC data straight into an array of integers somehow.

While I've got over the scaling issue I'm still curious if this is the best way of going about this kind of thing.
You could unlock the VCS, select all the EventValue widgets and change their ranges to (0, 127).  

How do you want to use the Array of integers in your Sound?
I didn't think that would work? I tried that. I thought the VCS widgets still respond to OSC messages between 0 - 1 even if their display scales are 0 - 127. Maybe I messed that up when I tried it. Not that it's important to what I'm doing.

The integers represent a choice of 101 samples to be played. I was thinking I wold reserve using note numbers for specifying pitch. Maybe I should be sending this as some kind of MIDI CC over OSC? Although I guess that would be merged in to any other midi coming in - probably not a problem.

2 Answers

0 votes
hi,

donĀ“t know if I am getting you right/or this will be helpful:

I am using osculator as well, you can scale any values at scaling page (osculator->view->flip to scalings page)

cheers

siegi
answered Jun 21, 2016 by siegmaraigner (Practitioner) (410 points)
+2 votes

Since you don't care about seeing the widgets or updating the values while the Sound is playing, you could alternatively change your Python script to write the values out to a .txt file.  Then you could read the text file in Kyma using a Script module or a MIDIVoice module's Script field.

Depending on how you plan to use the array of numbers, there is also an option in the Wave Editor to read numbers from a text file and turn them into a Samples file.

See Jon Bellona's articles in INSIGHTS magazine for some tutorial examples.

answered Jun 21, 2016 by ssc (Savant) (126,620 points)
I read that great article by Jon Bellona. I got the impression that was more of an off-line thing rather than in real-time.

This is more of a performance interface I'm building. I've got a touch screen where I type in strings of symbols. These are processed using a python program and a stream of data is produced which represents samples to be played. These samples are then scheduled and played by a kyma sound.

My python program could dump out a CSV file instead of sending OSC - is it possible to make a kyma sound that would monitor and pick up changes in the CSV file and import it in real time or is OSC a better option?

Thanks for your answers!
In that case, maybe you could use a Multisample in Kyma.  Send the index of the sample as an OSC message.  The Index parameter of the Multisample expects values in the range of 1 to the number of samples specified in the Samples field.  In the Gate field, you could use: !Index hasChangedInLast: 0.2 s
...