Some thoughts about modular

[Al Magnifico]

Hi

I'm new to muzys and mu.lab, checked the demo today and was very impressed. That what I thought was a beginners garage-band-like DAW is in in fact a promising modular host with some outstanding features. It scales very good, you can just record keyboard playing right into tracks or build complex modular setups like in audiomulch or energyXT (the old, real one, of course ).
Some questions came up and I'm not sure if these are something i missed or just not (still not) implemented:

• I could switch the rack view into modular. The racks are shown as objects, but not the sequences routed into the racks. I understand, that a sequence can also send into Objects inside a rack, a send inside a rack can sends to another rack so no chance to have a correct signal flow anyway, this is somewhat confusing.

• There are some Objects in the MUX or MuSynth Editor (I think, it is the same anyway), that have Event Type Outputs (like LFO, Enveloe etc...). Are this the same kind of Event Type Signals, that are used for MIDI Event Routing? How do I map this ? Which role plays the Mod.Mapper? If internal control streams are different from MIDI streams, it should have another color.

• When I record into an existing sequence, I got a requester for Overdub (merge called), Overwrite, Making a new sequence (or part?) or punch. what means punch?

• As I see it right, the tracks are a pure visualisation, because it's fully object oriented, each sequence has its own target and you can even place several parts on top of each other in one track. So the "free" restriction is not really one

I have to stop here, some more thoughts to come later. I'll definitely stay tuned!

[muzycian]

I'm new to muzys and mu.lab

Just for your info:

'muzys' doesn't exist anymore.

Our company name = MUTOOLS
Our currently main product = MU.LAB

I could switch the rack view into modular. The racks are shown as objects, but not the sequences routed into the racks. I understand, that a sequence can also send into Objects inside a rack, a send inside a rack can sends to another rack so no chance to have a correct signal flow anyway, this is somewhat confusing

Hmm, i don't fully understand your question.

What exactly do you find confusing?

There are some Objects in the MUX or MuSynth Editor (I think, it is the same anyway), that have Event Type Outputs (like LFO, Enveloe etc...). Are this the same kind of Event Type Signals, that are used for MIDI Event Routing?

Yes.

There are 2 types of signals:

Audio = the red connectors

Events (aka MIDI) = the blue connectors

How do I map this?

How do you mean?

Which role plays the Mod.Mapper?

The Modulation Mapper remaps the value incoming modulation events.

So for example, if you set an LFO as input, you could tweak the level and polarity of that LFO.



In the above picture example, we've set the Minimum to 0 % and the Maximum to -50%. This way the level of the input signal is reduced to 50% AND inversed.

When I record into an existing sequence, I got a requester for Overdub (merge called), Overwrite, Making a new sequence (or part?) or punch. what means punch?

Please see http://www.mutools.com/mulab/docs/recording.html

As I see it right, the tracks are a pure visualisation, because it's fully object oriented, each sequence has its own target and you can even place several parts on top of each other in one track. So the "free" restriction is not really one

Indeed, you can put a lot of parts on top of each other.

But it may be easier to work if you have an unlimited amount of tracks.

I have to stop here, some more thoughts to come later. I'll definitely stay tuned!

Cheers!

[Al Magnifico]

I could switch the rack view into modular. The racks are shown as objects, but not the sequences routed into the racks. I understand, that a sequence can also send into Objects inside a rack, a send inside a rack can sends to another rack so no chance to have a correct signal flow anyway, this is somewhat confusing

Hmm, i don't fully understand your question.

What exactly do you find confusing?

I thought, the modular plugin area were a kind of complete routing scheme for the application. Other in- and outlets, like MIDI/Audio in/out are also present, but not the data coming from the sequences. Signal Routing from a sequence can only be done from the arranger, sequence properties panel. I mean, it's just an inconsequence in the visualisation, not really confusing.

There are some Objects in the MUX or MuSynth Editor (I think, it is the same anyway), that have Event Type Outputs (like LFO, Enveloe etc...). Are this the same kind of Event Type Signals, that are used for MIDI Event Routing?

Yes.

There are 2 types of signals:

Audio = the red connectors

Events (aka MIDI) = the blue connectors

That would mean, the events coming from an LFO, Wobble Generator or ADSR are in fact MIDI events? If I route a LFO to a VSTi, how could I tell the LFO, which controller or vst parameter should be modulated by it? (In fact nothing happens when I do so). The generated events from the LFO can only be used with other objects like the WTF oscillator that have dedicated event inputs for a parameter. So these signals cannot be exactly from the same type, at least from the users sight.

I'm sure it would be very cool if there were no differences in modular routing, just connect every event source to any type of object. I this case you have to tell the object, which parameter has to be controlled by the event input. With MIDI Events there is no problem, because we can do this with the Parameter Map, but for the other ones such mapping is missing.

A possible solution would be, an option to define additional control inlets for dedicated parameters (or Metaparameters) at every object. Another one: a "translator" object, that maps those unspecified control events to specific MIDI events. First I thought, the Mod.Mapper does exactly this, but it just adds a function that's in the MIDI mapping table also for these control streams. So maybe the mod.mapper is indeed the right place to add this function.

A third one ( the worst) would be to drop the rocket science and use green cables and inlets to visualize, that you just cannot control a plugin by these signals.

But the other two opens more possibilities, especially when you think about future new synth elements like step sequencers or free-form envelopes.

[muzycian]

I thought, the modular plugin area were a kind of complete routing scheme for the application. Other in- and outlets, like MIDI/Audio in/out are also present, but not the data coming from the sequences. Signal Routing from a sequence can only be done from the arranger, sequence properties panel. I mean, it's just an inconsequence in the visualisation, not really confusing.

But a Part is time-based!

How would you visualize both time-based and non-time-based objects in the same editor?

Yes.

There are 2 types of signals:

Audio = the red connectors

Events (aka MIDI) = the blue connectors

That would mean, the events coming from an LFO, Wobble Generator or ADSR are in fact MIDI events?

They are events, not necessarily MIDI events.

MIDI events are a sub group type of events.

If I route a LFO to a VSTi, how could I tell the LFO, which controller or vst parameter should be modulated by it? (In fact nothing happens when I do so).

That doesn't work. (yet?)

The LFO etc... can only be used with the internal MU.LAB plugins.

The generated events from the LFO can only be used with other objects like the WTF oscillator that have dedicated event inputs for a parameter. So these signals cannot be exactly from the same type, at least from the users sight.

They're all events.

But within this type, you got several event types like notes, controllers, parameters, etc...

I'm sure it would be very cool if there were no differences in modular routing, just connect every event source to any type of object. I this case you have to tell the object, which parameter has to be controlled by the event input. With MIDI Events there is no problem, because we can do this with the Parameter Map, but for the other ones such mapping is missing.

A possible solution would be, an option to define additional control inlets for dedicated parameters (or Metaparameters) at every object. Another one: a "translator" object, that maps those unspecified control events to specific MIDI events. First I thought, the Mod.Mapper does exactly this, but it just adds a function that's in the MIDI mapping table also for these control streams. So maybe the mod.mapper is indeed the right place to add this function.

A third one ( the worst) would be to drop the rocket science and use green cables and inlets to visualize, that you just cannot control a plugin by these signals.

But the other two opens more possibilities, especially when you think about future new synth elements like step sequencers or free-form envelopes.

To be honnest, though i got an impression of what you mean, i'm not sure if i fully understand.

Anyway, let me say this:

There are many things on the Whishlist, so that's why the "Most Wanted Feature" poll was there.

Extending the modular functionality didn't seem to be a priority right now.

Which i can understand.

Because imo first the current functionality should even be more finetuned.
And A LOT more patches should be made with the current modular modules. Already soooo many possibilities!!

Regarding the different types of signals:

There are only 2 main types of signals: Audio and Events.

But there are different types of Events, e.g. note events (cfr midi), controller events (cfr midi), parameter events, modulation events, ...

An LFO generates modulation events.

If you connect the output of an LFO to the 1st event input of a Filter, then it will modulate the cutoff of that filter.

If you connect the output of an LFO to a VST plugin, it won't do anything, because a VST plugin doesn't know MU.LAB's modulation events.

I understand that there could be a 'translator' plug, but as indicated, that's not yet planned for the very short future.

As i very much believe that we first should deepen out the current functionalities! And neatly evolve step by step.

[Al Magnifico]

But a Part is time-based!

How would you visualize both time-based and non-time-based objects in the same editor?

Yes,you are right. Didn't realized that even the parts can have different targets. That would make really a mess.

As i very much believe that we first should deepen out the current functionalities! And neatly evolve step by step.

I was far from proposing a feature request for modular, I also noticed the poll, though I didn't voted for the sampler. It was just something that came in mind.
best regards
Al

[muzycian]

Thanks Al!

Will do my best to let MU.LAB evolve as good and as fast as possible.