timing in blue (stream-accurate sequencer)

[tester]

I'm not sure if anyone played with such idea.

Let say, that I have an text array of time points, like this:

0
12.45
60.12
1800.20
and so on.

these values represent time points at given time resolution. Here - only few to simplify the idea.

Let say, that in the app - I have few separate wave players (i.e. each uses different audio data stored in mem, they are mixed).

Now, at each time point - I'd like to trigger one of these wave players, to play its audio data.

*

Why in blue?

Let say, that I have an exe app, that allows to export long audio files (up to 60-90 minutes?) from a randomized and repeatable sequence. In order to create audio file, in which audio buffers (from wave players) are synced to timeline - this can't be done in green, because when FS is exporting audio data using mems - everything else is blocked.

Anyone played with such stuff so far? Has anyone a schematic template that could handle such scenario?

*

I guess, that this could use multiple counters, that run at different speeds in regards to each other, and the array would be stored via mem (and recalled from there) in some way (related to these counters).

[tester]

Here is ageneral concept of a stream accurate (synced in blue) sequencer.

External textual data (which follow certain syntax) are split onto timing values and parameters to propagate.

Time is set in seconds.miliseconds, and is sent to two mems (s, ms). This is because - streams generally use float data, and we want to have unlimited accuracy and no mess. So two mems in paralel - represent list of time points.

Then we have a sample accurate, blue timer. One part counts seconds, and the other part - miliseconds. Since the base of timer uses samples - it was necessary to do a trick, to not exceed the float range. So after each second/milisecond - a 1-sample pulse is sent (and counter resets), and these pulses are added on stock - and they represent time. I used some of my old modules (to which MyCo, Trog and KG contributed as far I remember). [If I did not messed something, this part works internally correctly].

And now we have a trick. Mems show single time point (at certain index) at which other data should be changed and propagated. When timer reaches that point (time is compared to time, s.ms to s.ms) - a pulse is sent, and since pulses are added to each other - it increases the index by one, which in turn changes the output of all mems. So the timer goes to the next value, where a pulse will be sent and so on. Pulses are sent only at timing points from the list.

Next part is a way how the values are spread and used. In one of mems - slot numbers are stored. Slot number is compared to unit ID, and if it matches, then initialization pulse and other parameters are passed thru. You may put into slots whatever "devices" you want, they should be initialized by a pout pulses (some additional work may be required).

Note. This is set currently for 44100 reference (this limitation is related to my project, but you may play with it).

*

To do (and what I need).

1)

In my project - each slot will contain a single waveplayer. Stock waveread works correctly only up to c.a. 6'20" (at 44100), and then it fails, but thanks to KG - we have better way, which works with any size of audio files.

Such waveplayer (it's precise counter I guess) needs some modification however. Equivalent inputs of "play" (reset counter and start from beginning), "stop" (reset counter and don't count) and "loop" switch (after reaching the end of file, start over again). Which means, that initial state of the counter should be "offline" (not playing).

I guess, we may simplify here. KGs waveread works in loop, so this is ok. "offline" (stop) could be performed virtually, by multiplying output by 0. So the slot will be always running, but output would depend on users needs. So the only thing required is an input for resetting the counter to 0.

All has to be in blue, so that it can be used to offline audio export.

2)

Which leads us to the second issue. If I understand corectly, wavewrite, that writes to mem - has the same limitation as the stock waveread. So for longer audio export - we need modified wavewrite.

*

If this will work like I think, then:
- timing counters will do the initialization and proagation of parameters,
- waveread counters will do their job with outputing the audios of individual waveplayers, and
- general counter associated with wavewrite and saving - will coordinate all, to produce a track that is for example 30 minutes long.

[tester]

attaching KG's waveread. I guess, the blue "reset" should come somewhere onto offset.

"stop" and "loop" equivalents would save some cpu.

[tester]

simple working adaptation with stock waveplayer.