First time here? Check out the FAQ!
x

Hot value for start time in SetDuration (and sane duration)?

+1 vote
72 views
First, I don't want to use Timeline, because I understand it even less than the Sound prototypes and have even less of a clue as to how integrate it into my Python OSC code.

So. With that caveat out of the way: I want my Python code to send an OSC message to change the start times of 16 samples, relative to the time when a button is pushed in the UI generated by the Python code. I don't want to change the duration of the samples, or anything else in my current sound. I just want to add in a different "wait", or "sleep" for the onset of each sample's playback.

The start time is in seconds, and is read from a JSON file produced by an editor I've written.

The samples are coming from files listed in 16 MultiSample Sounds. They are all of different lengths, and set to loop.

I had hoped it would be something like "default" for the duration and "!Whatever s" for a hot value for number of seconds. But, alas, it appears it is not so.

Thanks
asked Jul 16 in Sound Design by kevin-cole (Practitioner) (920 points)

2 Answers

0 votes
 
Best answer

My solution:

Multisample Sound

Gate ((!SignalOn1 * !Replay) turnOnAfter: !SignalWait1 ms) gateWhen: (!SignalOn1 * !Replay)

  • !Replay and !SignalOn1 are toggles whose values are either 0 (off) or 1 (on).
  • !Replay is shared by 16 Multisample Sounds (eight "noise" and "signal" pairs mixed and sent to one of eight loudspeakers) and is controlled by the end user (i.e. clinician's client)
  • !SignalOn1 and !SignalWait1 (with seven additonal pairs, plus eight corresponding !Noise... pairs) are read from a JSON preset file created by the clinician prior to the client's session and are not controllable by the end user.

The idea is that the clinician decides which speakers will have signals or noise being emitted, and when, after the client presses a "Start" button, those samples will play. The client can start, stop and restart at will, which controls the !Replay.

answered Sep 7 by kevin-cole (Practitioner) (920 points)
0 votes

In the Multisample Gate field, you could try using:

!Trigger turnOnAfter: !Delay s for: !OnDuration s

That way you could control when each one starts relative to a master !Trigger (and how long it stays on and looping).

answered Jul 16 by ssc (Savant) (75,210 points)
My problem there is that my trigger is the combination of two toggles. When the two toggles are OFF (0.0) the sound should never play. I've tried variations like

(!Replay * !SignalOn1) turnOnAfter: (!SignalWait1 / (!Replay * !SignalOn1)) s

but no matter what I do, the sound always starts playing. (I want !SignalWait1 to default to zero, but I don't want the sound to turn on if either !Replay or !SignalOn1 are zero.)
Check to make sure that the initial preset values for !Replay and !SignalOn1 are both zero. You could also use the construct:
(!SignalOn1 gateWhen: !Replay) turnOnAfter: !Signal1Wait s
I tried the gateWhen variation. No joy.  I also tried turning all !SignalOn's to zero (off) and then toggling the !Replay. Same result as before. It plays when !Replay is clicked on or clicked off.

In the VCS presets, the !Replay preset is always zero (OFF). However, by design, the state of !SignalOn1 is generally intended to be one (ON) and so, is preset that way. The Python code that drives the system reads  a JSON file created by a configuration program that researchers use to set up the experimental conditions, where they can specify that a particular Signal or Noise be zero (OFF).

The configuration program allows them to determine which loudspeakers will be producing which calibrated "noise" samples (or none) along with which calibrated "signal" samples (or none). It also determines the initial level of playback for the each of the samples. All that's working. But the third thing the config program will eventually do is determine the onset time for each of the samples, which is what I'm trying to implement now.

I can send .kym (and my failed attempt at making it into a .ktl)...
For now, please use turnOnAfter:for: (include the for: tag with a duration).

We have found and fixed a problem with #turnOnAfter:. The fix will be available in  the next update to Kyma.

For your example, you could use:

(!SignalOn1 gateWhen: !Replay) turnOnAfter: !Signal1Wait s for: 0.1 s
...