Fast & reliable way to 'scan' content of a control sequencer

TEMAS

I'm making lots of performances at the moment where multiple control sequencers are used to 'store' constant modulation settings which I send through buses to different slots.

The data is received and accessed using a simple value switch + sample hold method, i.e if control input = 'x', then we sample & hold the status.

For sending the data, I've come up with a bunch of different methods, some more reliable than others, some cheaper than others, some faster than others. Just wondering if anyone else has a method they use that I haven't thought of.

Cheers

Electromagnetic Wave · Posted: Fri Jan 29, 2016 5:58 pm Post subject:

Hi TEMAS,

I don't know if you know these patchs .. I modded the building blocks from selvmarcus for my purpose :

8voices-to-fx.prf2
Experimental perf sending signals of 8 voices to fx area using multiplexing ( 4 pairs ).
All clocks are synced by sending a click on bus1 at patch activation.

8audio-ovr-bus1+.prf2
DIY 8 channel audiorate mux/demux (12 kHz sampling for each channel)

http://electro-music.com/forum/post-70953.html#70953

I modded this one from ik to send chord from keyboard to other slot. Useful to use with the ScalaG2 generated patch to play a chord to another patch that is locatate to other slots :

[bblock] lo-hi signal splitter.pch2
hi/lo note separator, splitter. Highest OR lowest note substracted from a chord, audio processed separatly then recombined with the rest of the chord.
http://electro-music.com/forum/post-32633.html#32633

Smile

Tim Kleinert · Posted: Sat Jan 30, 2016 2:53 pm Post subject:

When doing multiplexing with synchronized mux/demux clocks (instead of passing around the address pointer on an extra buss), it's important to keep in mind that interslot busses introduce a latency of 24 samples, whereas VA-to-FX busses do not.

This seemingly minute issue can create real problems (or even insurmountable obstacles) when fast (or immediate) intercommunication between slots (or VA and FX area of one slot) is required. (This is what prevented me from creating a workable solution for alternate polyphonic voice allocation schemes. It also ruined my endeavors for studio-quality reverb algorithms. Sad

)

TEMAS · Posted: Sun Feb 07, 2016 4:34 am Post subject:

Hi guys. Thanks and sorry for not responding sooner; I had a load of work on last week and as usual my G2 experiments had to go on hold. Sad

I've encountered the bus latency first hand, usually I find about 0.26ms delay triggering events makes sure they are in sync but I've never measured it; I don't even know how to. What does 24 samples at 96khz equate to in ms?

I think you and I have been trying to do similar things with voice allocation from an alternate slot. I have had some success with this and I will share my progress at some stage when I'm sure everything is 100% reliable..

My work with the G2 for several years now has been primarily to create 'work station environments' where each key or pad from a controller plays something completely different. Usually I have 16 pads and a complex sequencer set up to activate and send vast amounts of data from one slot to another. MIDI just isn't fast, accurate or efficient enough for this kind of approach. I made one environment for example where I could send and refresh 42 modulation settings per voice from one slot to another within under half a ms, but I only had 3 voice polyphony left at the end. In these performances I also made it possible to allocate the voice from number that is activated from the pad.

Anyway, I have had another thought today, which is whether it would possible to make a mux send return that is voice specific. Theres a 16>1 muxer patch I recall someone designed ages ago and I'm wondering if (in order to make a patch more efficient) I could make the inout from bus 1 go to voice 1, bus 2 to voice 2, etc. That way I'd only need one 16>1 muxer, but there would actually be 64 elements being sent and received.

I'll give it a go today.

TEMAS · Posted: Sun Feb 07, 2016 5:36 am Post subject:

Hmm, I can't the 16>1 multiplexer. Maybe it was Tim's 16>2 that I was thinking of.

Anyway. This is what I originally meant about a Scanner. The purpose of this module is to send multiple static numbers as fast and efficient as possible from one slot to another. In this case it takes 0.73ms + bus latency to send 16 numbers through one bus.

I'm going to try and make this voice specific today.

Scanner Test2.pch2

Description:

Download (listen)

Filename:

Scanner Test2.pch2

Filesize:

3.56 KB

Downloaded:

3317 Time(s)