Notifications
Clear all

Sequential Mono Latch Chains (SML Chains)


glenjdiamond
(@glenjdiamond)
Trusted Member
Joined: 1 year ago
Posts: 68
Topic starter  

Excuse if this has already been asked for...  !!

I know how to Mono Latch a Layer (or Layers) to listen out for a key depression, and to stop when that key is depressed once more.

SML Chains (Sequential Mono Latch) could be similar but with a bit more logic built into sequentially triggering layers.

Rule One - There must be at least one instrument (or unify) layer existing in the patch.

Rule Two - Only one layer within an SML chain can be active.

Rule Three - There can be more than one SML chain running simultaneously (with the 1st SML chain acting as the master timer).

Rule Four - Only the Master Timer SML may start other SML chains.

how would this work? -- Let's say we have six DRUM layers each with their own MIDIBOX relating to different parts of the tune, and as well as that we have more layers dedicated to live playing, and we have layers with MIDIBOX prep'd for accompaniment melody and/or chord pad layers...

Looking at Rule Three above we can see that the 1st SML chain will be the master for the midi timing.

In the main BROWN MIDI area we "add" an "SML" - it instantly becomes the master SML01

SML01 will ask us if it is to provide timing (with parameters) or if timing is from the DAW.

SML01 will also need to know what the trigger event is (could be a key depression or another MIDI CC trigger which can be MIDI learned).

Now that at least one SML chain has been declared, we look at our layers and decide that one of the drum layers is the 1st to be activated.

Because SML01 has been declared in the main BROWN area, in the layer BROWN areas an "SML" button appears.

We click the layer SML button for our first drum layer and it asks us length parameters "??/Measures" and/or ??/64ths.  Because there is only one SML chain (SML01) it defaults to SML01 so that this layer becomes the 1st layer in the SML01 chain of events.

Any instrument/unify layer assigned to an SML chain will have a count-down showing us the amount of measures and/or 64ths remaining (this will countdown in real time when that layer is activated by the SML chain.

Continue to add subsequent drum layers to SML01.

We now have a chain of inactive layers where only one of them will activate according to which SML chain they are members of and according to the measure and/or 64ths length parameters of previously activated layers within the same SML chain.

Adding an extra SML chain for musical accompaniment...

In the main BROWN MIDI area we "add" an "SML" - this becomes SML02 (chain 2)

We now need to revisit the master SML01 and instruct it to start SML02 after a length of time (or immediately).  Remember that only SML01 has the master timing and master trigger.

SML02 and subsequent SML's have no parameters, they are place-holders for a sequence of latch triggers.

Looking at our Melody Layers (each with its own set of MIDIBOX's) we can add SML02 to them.  Remember that there is already a timing parameter for chain SML02 within the master SML01 to tell this layer when to begin (it is the 1st layer in the SML02 chain).  But we still need to define how long this layer should play (measures and/or 64ths).

If we have another Melody layer that needs to start at the same time as the 1st SML02 layer, we would need to define a new chain (SML03) and instruct SML01(the master timing chain) to start SML03 at the same time as SML02.

SML02 and SML03 may still be used as triggers for chains of additional melody layers that follow each other, that's a simple case of allocating either SML02 or SML03 to a layer and telling that layer how long it will play for (only one layer in each chain can be active, but many chains may be active simultaneously).


Quote
getdunne
(@getdunne)
Member Admin
Joined: 3 years ago
Posts: 3448
 

@glenjdiamond

Thank you for the very detailed suggestion, but this sounds like more of a dedicated product than a simple addition to Unify. To be honest, I doubt it would appeal to enough people to justify the effort of development.


ReplyQuote
glenjdiamond
(@glenjdiamond)
Trusted Member
Joined: 1 year ago
Posts: 68
Topic starter  

I suppose, what I am trying to describe, is a latch feature that doesn't just trigger a repeated drum sequence, or a repeated MIDI melody.

*well - it would repeat if the MIDIBOX MIDI file was shorter than the length of the sequence!

This would be a sequenced event processor that would only work with Unify, specific to Unify layers.

The benefits would be a triggered backing track that follows the sequence of a song/tune.

Can also be useful for MIDI controlled DMX lighting effects that would also react in sequence with a song/tune.

I can see this as being useful in a live environment for the standalone version of Unify.

It would make it possible to create a patch that houses the entire backing track and also has spare layers for live playing.

 

 


ReplyQuote
getdunne
(@getdunne)
Member Admin
Joined: 3 years ago
Posts: 3448
 

I'm very interested to hear others' thoughts on this. It's an intriguing idea for sure.


ReplyQuote
zimp
 zimp
(@zimp)
Eminent Member
Joined: 1 year ago
Posts: 22
 

I was hoping others would chime in, but maybe the original post was a little bit to difficult to grasp, because I'm still not sure what is suggested here, but that could be entirely my fault for not understanding the English language enough. Am I right that a user can fire a sequence of midifiles (using MidiBoxes), but only one at the time in a certain group? It can have its usefulness ,but what about constructing a midifile that has all the info in it (like 2 bars for intro, 2 bars for verse, 1 bar for a little break etc) and set the from-bar and length controls under some kind of macro control in combination with a "quantized event mechanism" so that jumping from one part of the midifile to another part happens on a musical timing, i.e. on the next bar/beat one?


ReplyQuote
glenjdiamond
(@glenjdiamond)
Trusted Member
Joined: 1 year ago
Posts: 68
Topic starter  

@zimp Hello - not quite what I was thinking.

I wanted to ask for a Master Sequencer that will trigger a MIDIBOX to start on a layer.   The master sequencer is similar to a MONO MIDI LATCH where it listens out for a MIDI trigger (could be the lowest key on the keyboard, or it could be a MIDI controller button).

Each participating layer will need to know how long its sequence is (how many measures/bars and/or how many 64ths).

Participating Layers need to be assigned to a group.

Only the master sequencer will know when each group starts.

The triggered layers will initially be "inactive" and won't respond to any key presses. (You could play a few chords live before the sequence is triggered using the layers that are not assigned to groups).

When the triggered layer becomes active (from the master sequencer) the layer will simply play a MIDIBOX and won't respond to any other key presses.  (This is because it is a backing track).

Then another layer can be sequentially triggered from the group after the above layer finishes (sequence length stored in the layer parameters).

If we want multiple layers to be triggered at the same time... that's when we have several groups that are controlled by the master sequencer.

The master sequencer will be in the top most brown MIDI section of Unify.  Also the groups will be shown (but they have no parameters)

Layers can choose to belong to any of the groups... when they become a member of a group , the layer will need to have a sequence length and it will become inactive to any live playing.

The groups are for sequences of layers (one after the other) - that's why we would need more than one group if multiple layers are playing at the same time.

The Master Sequencer will have the timing info and the trigger info (what key will start the groups).

Imagine having a number of layers dedicated to live playing - they don't take any notice of the master sequencer because they are not members of a gorup and they behave the same as any normal layer in a unify patch.

Imagine in the same patch also having a backing drum track consisting of several layers (each with their own effects and their own MIDI track)

The drum layers (backing track) could be assigned to GROUP1 (which is triggered by the master sequencer - listening for a trigger key/button)

Imagine having a backing musical track consisting of several layers...

Imagine having a number of layers dedicated to controlling DMX lighting over MIDI...

All of the above will be in ONE PATCH!!!   So a patch will be able to play a backing track and control lighting whilst you play live over the top.


ReplyQuote
getdunne
(@getdunne)
Member Admin
Joined: 3 years ago
Posts: 3448
 

@glenjdiamond

Thank you for the expanded description. As I said before, this sounds like something which should be a separate app which works with Unify, rather than a lot of intricate new features (which will not interest most users) added within Unify.

The reason I added OSC support to Unify is to support exactly this type of development. It may not yet provide enough functions to support what you are proposing, but it will be more manageable and practical for me to add only the necessary OSC functions to Unify, while someone else develops the master-sequencer app as a separate project.

Also, are you 100% certain that the functionality you're after cannot be accomplished with established live-host apps like AbletonCantabileGig Performer, etc., hosting as many Unify instances as might be required (basically, one for each layer-group)? It would be nice not to reinvent the wheel.


ReplyQuote
glenjdiamond
(@glenjdiamond)
Trusted Member
Joined: 1 year ago
Posts: 68
Topic starter  

@getdunne Hi,  Yes, I understand that there are specialised DAW apps where Unify may exist as a VST.

I suppose I was thinking in terms of having a stand alone version of Unify that can do some simple sequencing without the overheads of needing a DAW running in the background?


ReplyQuote
getdunne
(@getdunne)
Member Admin
Joined: 3 years ago
Posts: 3448
 
Posted by: @glenjdiamond

I was thinking in terms of having a stand alone version of Unify that can do some simple sequencing without...

I understand what you're after. My concerns are:

  1. What you describe is not actually simple.
  2. The development effort will be substantial, and I doubt that enough people will pay enough extra for it, for it to be worthwhile.
  3. The tech-support effort (which earns nothing and continues forever) will be colossal (because it's not simple).

ReplyQuote
glenjdiamond
(@glenjdiamond)
Trusted Member
Joined: 1 year ago
Posts: 68
Topic starter  

Not to worry - I'm enjoying Unify as it stands - I think I'm suffering from the age old problem of thinking in human and not understanding the logic/techy stuff that makes it happen!!  


ReplyQuote
zimp
 zimp
(@zimp)
Eminent Member
Joined: 1 year ago
Posts: 22
 

Maybe it boils down to the question what the intentions of Unify are? If we don't know what the boundaries are then we really have no clue what is feasible or not. If Unify stays primary as a host for other plugins, as it is now and doing a great job, well I perfectly understand that with the reasons Shane has mentioned. Getting Unify OSC aware is a truly nice addition, but it will make people create their own little islands and somehow that feels sad.


ReplyQuote
getdunne
(@getdunne)
Member Admin
Joined: 3 years ago
Posts: 3448
 
Posted by: @zimp

Maybe it boils down to the question what the intentions of Unify are?

Our intention is to establish a viable music-software business. To do this, we must carefully weigh the effort required to develop new features, based on the potential for new sales.

Getting Unify OSC aware is a truly nice addition, but it will make people create their own little islands and somehow that feels sad.

 

I hope to encourage the development of open-source companion programs, which should help to avoid the "little islands" problem. Adding features to Unify itself is laborious, because C++/JUCE is a low-productivity development tool. OSC enables use of higher-productivity, easier, more well-known programming languages. All of the features @glenjdiamond has specified would be far easier and quicker to code in a language like C#, Python, etc., and can be safely open-sourced without revealing any of Unify's core code.


ReplyQuote
Share: