No Volume control in the Multisampler Zone Editor

[liquidsound]

This needs attention I think....
In the Zone Editor you have no control for the audio out going to your speakers but the OS volume control panel.
This thing is bypassing everything straight to the Audio Out.
Last night (2am) I was working on a drum pattern and I kept my racks volume at the bare minimum but left my speakers as usual... HIGH!
No need to say anything else....

Is there a hidden knob anywhere?

[MuTools]

That's strange, there is a Gain parameter for each multisample zone:



Isn't that what you're seeing?

[liquidsound]

I forgot about that one but it doesn't solve the problem well, because you need to change each one of them when testing while composing.
A Gain control before going to the Audio Out should be there somewhere.
Or the raw sample sound should pass through the plug in before going to the audio.
Individual controls so deeply nested are a pain and no so efficient...
I understand the individual Gain, it necessary, but a gate somewhere on the line would help in situation when the right master and speakers volume is set for a purpose.
Kind of the Metronome implementation. It is independent but subject to a control before going out.

[MuTools]

I forgot about that one but it doesn't solve the problem well, because you need to change each one of them when testing while composing.
A Gain control before going to the Audio Out should be there somewhere.

Euh, i'm not sure if i can follow.
You could insert a MixerStrip before the Audio Out if you want.
Doesn't that solve the problem?

Or the raw sample sound should pass through the plug in before going to the audio.
Individual controls so deeply nested are a pain and no so efficient...
I understand the individual Gain, it necessary, but a gate somewhere on the line would help in situation when the right master and speakers volume is set for a purpose. Kind of the Metronome implementation. It is independent but subject to a control before going out.

I don't understand. Can you please elaborate a bit more about the context you're talking about. Thanks.

[liquidsound]

You could insert a MixerStrip before the Audio Out if you want.
Doesn't that solve the problem?

Out from where?
I had the multisample in a rack, the rack had volume down to nothing and so the master and I even mute the rack, master and track and still the sample sound, when triggered from the virtual keyboard inside the sample editor, was going to the speakers.

If I am missing something, please point this out because it seems that there is a way, otherwise you would not be puzzled by this.

I will re-Try this tonight but I am pretty sure that's the way I did it.

[MuTools]

Ah, ok, i understand what you mean.

It's when you're monitoring keys in the multisample editor.

Mmm, right, this goes straight to the Session Audio Out.

How should it be monitored then?

[liquidsound]

Ah, ok, i understand what you mean.

It's when you're monitoring keys in the multisample editor.

Mmm, right, this goes straight to the Session Audio Out.

How should it be monitored then?

I do not understand technically why it's not going through the Multisample plugin its self rather then straight out to audio, that way it's not going to disturb the mix.
Is this possible? Is it a good solution? Maybe I miss some workflow points by doing that.

[MuTools]

A multisample can be used by different multisample players.
In that case, which multisample player should play it?

[liquidsound]

From the one that I just open to get to the samples... No?

[MuTools]

I'm afraid it's not that simple, unfortunately.

Imagine you openened a patch like this:



Now when clicking the multisample keyboard, should you hear the ring-modulated sample or the straight sample? I think the straight sample because you're monitoring the multisample object, not the MuSynth patch object.

Another example:



Imagine the piano playes immediately and the strings have a slow attack, fading in into the decay of the piano, more in the background i.e. at lower volume i.e. typical patch example.

Now when editing the strings multisample, when you click the keyboard, would it be ok if you hear the piano loud, and after a while the strings in the background? I don't think so.

These are just two simple examples which tell me that when monitoring a multisample zone, we should hear the multisample itself.

What do you think?

[AndreasD]

Jo,

Just root it though the Multisampla. It will be in "context" but that's what you want in a multilayer setup.

When I replace the sampler with a standard osc it's routed in context as well!
So, imho, it would be consistent with the other audio generators to monitor in context.

When I layer oscs I often need to switch them off to finetune one. This is fine and expected and leads me to a little request to give the LFO's an ON/OFF switch as well. Currently my mostly used way to silence an LFO is to delete its connections or to mute the input on the receiving site.

Andreas

[MuTools]

Jo,

Just root it though the Multisampla. It will be in "context" but that's what you want in a multilayer setup.

Which multisampla?

Ok, please explain me using the piano+string example above.

Edit: I mean: Imagine there are two multisamplers in a patch, both playing the same multisample but at different pitch. Then which multisampler should be used to monitor that multisample key?

When I replace the sampler with a standard osc it's routed in context as well! So, imho, it would be consistent with the other audio generators to monitor in context.

Euh, i don't understand the link cause there is no multisample editor in the sample player.

When I layer oscs I often need to switch them off to finetune one. This is fine and expected

Yes, that's true. I'll take this aspect into account already. But i'm still puzzled by the above questions.

and leads me to a little request to give the LFO's an ON/OFF switch as well. Currently my mostly used way to silence an LFO is to delete its connections or to mute the input on the receiving site.

You can also mute the connection itself: double-click it -> Mute

[liquidsound]

Jo, somehow the samples are going straight to the audio bypassing everything.
This make sense and it should be as you described in your examples.

Are the samples in a separated pool that a multisample taps into it? If so then a Gain, as with the metronome, could be used right before the audio out component. It should be quite easy to add it since there is nothing in between the samples and the audio out unit. If the samples are all going through the same (invisible) routing, just put it there.

I am making any sense? Where are the samples located and how they get to the Audio Out unit?

[MuTools]

Jo, somehow the samples are going straight to the audio bypassing everything. This make sense and it should be as you described in your examples.

Are the samples in a separated pool that a multisample taps into it?

The samples are in RAM, collected in the session sample pool, which is also accessible via Edit -> Sample Manager.

If so then a Gain, as with the metronome, could be used right before the audio out component. It should be quite easy to add it since there is nothing in between the samples and the audio out unit. If the samples are all going through the same (invisible) routing, just put it there. I am making any sense?

I'm afraid i don't understand your solution, no.
Maybe i'm missing something?

I do understand the practical problem you are stating here in this topic, but i don't immediately see a simple solution.

Maybe this tip: If you want to monitor a multisample key WITHIN its modular context, then play that key via MIDI or via the Virtual MIDI Keyboard.

[liquidsound]

Well the point of my post is that when I want to monitor a sample directly from the virtual keyboard where the samples are layout it is impossible to control the output volume of MuLab but going to the window control panel and adjust the volume there or the speaker's volume. It doesn't make sense!

OR each time I am checking or monitor each sample, as in the drum set, I need to change their gain temporarily, just for checking, or do the above maneuver in order to save the speakers because this thing goes at full gain out to them and the only gate is the operating system or sound card volume control.

It's a weak link in the chain. Being in the RAM then means that has one foot in MuLab and the other in the OS and MuLab losses control over it.

This can't really be addressed?