Cycling 74 » Topic: sample cues midi

sample cues midi

CBKnerdlab — Sat, 07 Mar 2009 16:23:53 +0000

hi,

i working on a patch where a soundfile triggers midi events on certain cues.
at this stage, i’m figuring out which objects to use.

sfmarkers~ and count~ seem to give some useful results.

what would you suggest?

concept = a soundfile plays, and at specified times triggers midi events (that control a dmx box)
the event times must be editable.

Re: sample cues midi

Holland Hopson — Sat, 07 Mar 2009 19:02:12 +0000

Here’s one quick approach. Loading a soundfile also references a coll file of cues associated with the soundfile. The time of each cue serves as the address with cue instructions following. For example:
240, light 1 sound 14;
1250, light 23;

When triggering a soundfile also trigger a clocker to keep track of elapsed time and bang out cues from the coll. So in the example above a cue fires at 240ms and another at 1250ms. Editing cues is as easy as changing the coll file. There’s no need to fire up an audio editor and add/change markers.

Re: sample cues midi

Patrick Delges — Mon, 09 Mar 2009 11:14:50 +0000

Holland Hopson wrote on Sat, 07 March 2009 20:02

When triggering a soundfile also trigger a clocker to keep track of elapsed time and bang out cues from the coll.

There is a timer in [sfplay~], so there is no need for another timer, check the [p "More Features"] in [sfplay~]‘s help file. Compare the time with a [>= ], not an [==] !

Quote:

Editing cues is as easy as changing the coll file. There’s no need to fire up an audio editor and add/change markers.

The reason why I created [sfmarkers~] was exactly the opposite: I didn’t want a user to edit coll files and eventually introduce errors or typos. Using a sound editor to create the markers was a more secure way for that project.
I do however agree that whatever solution you use, you should store your timings into a [coll] (that’s what I do, even with [sfmarkers~]).

Re: sample cues midi

CBKnerdlab — Mon, 09 Mar 2009 12:57:46 +0000

ok thanks,

this is what i’ve built sofar:
i’m not sure yet about the coll, it is maybe to difficult for the user. (im building this for an artist couple with no max experience whatsoever) so maybe i’m gonna use the sfmarker solution instead.

the coll file triggers on milisec. markers.
is this test accurate enough do you think?

suggestions welcome!

Re: sample cues midi

Patrick Delges — Mon, 09 Mar 2009 14:58:27 +0000

CBKnerdlab wrote on Mon, 09 March 2009 13:57

is this test accurate enough do you think?

The [coll s2midi1] will output the cue only if the time (in ms) sent from your [p h:m:s:ms] matches exactly one of its index. This will hardly be the case as the time sent is refreshed every 100ms (check into the patcher, there is a [metro 100]). That’s why you need to use a [>=], or a [>=~]->[edge~] and test against the next cue time stored in the [coll].

Changing the [metro] to [metro 1] is a (very) bad idea.

Re: sample cues midi

CBKnerdlab — Tue, 10 Mar 2009 14:03:57 +0000

in the sfplay~ help, “more features” is a message:

(about “current position(ms)” and “current position roundoff error (ms)”)

add these two signals using “hr” objects to get sample accurate position values for long files

what “hr” objects do they mean? hr.plus~ / hr.quantize~?
(i know they mean this :http://www.cycling74.com/twiki/bin/view/Share/JoshuaKitClayton)

my new patch is working fine, but i’m unsure about the timing