M3 Tests

[MuTools]

Thanks for the tips
But i still don't find this intuitive...i'd really like to see some simple grid options in the gui

...or this:

The latter i like much more. But not yet convinced that it needs the extra gui complexity. But will think about it some more. Please keep the link the that picture alive, i'm taking the link into my notes for review lateron (days/weeks). Thanks. No promises about M3 though, as M3 is heading towards release already.

[MuTools]

BTW I can't find the property for the knob size, is it in the FullRack.xml?

The size of the send knob is indirectly defined by the height of the plugin slots.

So you'll also have to increase the height of the plug slots, which means a redesign of the rack layout.

[Branis]

BTW I can't find the property for the knob size, is it in the FullRack.xml?

The size of the send knob is indirectly defined by the height of the plugin slots.

So you'll also have to increase the height of the plug slots, which means a redesign of the rack layout.

OK, thanks

[bpblog]

Because i don't yet see any advantage.

oh well, it's a cheeky subject. one's advantage is in this case someone else's disadvantage i think.

here's another good point by liquidsound though.

My argument is about hierarchy.

that's it. i can't grasp the concept in which a brilliant multisampler plugin is on the same hierarchy level as a simple bass patch. musynth, synthia, sampla and multisampla, should be higher up in the hierarchy than any of their patches.

[MuTools]

I can understand that request. Will think of it some more.

[sorohanro]

First of all, Congrats for the totally AWESOME program !

To understand my points of view:
I'm not a sound engineer, not a designer and I have no idea of programming.
I'm a musician and for me ease of use and the visual impact have a big importance (that's it I'm a image sucker).
If the interface is inspiring me and the usage of the program don't challenge me, I can focus on creation of music, which is the very reason of working with this program.

I worked with several programs in my life, in different studios (Cubase, Cakewalk, Nuendo, Reason 3, Reason 4, FL Studio, tried the demo of Pro Tools).
The easiest to understand are FL and Mu.Lab, MIDI editing is a dream in FL, an easy task in Reason 3, a pain in the a...eyes in Reason 4, hard task in Mu.Lab 2.7 and close to dream in Mu.Lab3!!!
It's close to be my favorite (maybe I need more time to get used).
I totally love the quantizing tools in M3


Sometimes designer's opinions and musician's opinions don't really match.
The best example to me is Reason 4. They gave up to one of the most useful tools just to be more ergonomic from designer's point of view.

Now, to finish my blabbering, the program is GREAT !!! but some useful tools are maybe too hidden in the context and maybe not easy to find for a beginner.
(That means "I can't find the line tool":lol: )

[MuTools]

MIDI editing is a dream in FL, an easy task in Reason 3, a pain in the a...eyes in Reason 4, hard task in Mu.Lab 2.7 and close to dream in Mu.Lab3

So what's missing in MU.LAB's sequence editor to make it heaven for you?

Now, to finish my blabbering, the program is GREAT !!! but some useful tools are maybe too hidden in the context and maybe not easy to find for a beginner.(That means "I can't find the line tool":lol: )

You mean the line tool for drawing velocity beams in the sequence editor?

[gemada]

Thanks for the tips
But i still don't find this intuitive...i'd really like to see some simple grid options in the gui

...or this:

The latter i like much more. But not yet convinced that it needs the extra gui complexity. But will think about it some more. Please keep the link the that picture alive, i'm taking the link into my notes for review lateron (days/weeks). Thanks. No promises about M3 though, as M3 is heading towards release already.

Glad you like it
A begginer or someone not familiarized with MU.LAB would indeed appreciate this grid stuff...IMHO i can't see why this is an extra gui complexity...it's so clean and simple...well it's up to you.

Another thing: FILE, EDIT and HELP popup menus should really appear bellow the buttons...i think someone noted that it also happens everywhere (where it has buttons and menus).

Thanks again

[pljones]

I shall do my usual wander by and throw something into the conversation then wander off without having actually been involved...

What if VST patches could be tagged and browsed in the library - i.e. you could tag a patch in a VST plugin as "bass" and it would appear under the "bass" folder and, when selected, load up the appropriate VST and select that patch?

That would put the VST plugins on the same level as the built-in synths and effects and on a separate branch from the patch library. So when you clicked to insert a plugin, you'd have "Create" and "Browse" as top level options; under Create, "Mu-Synths", "Mu-FX" and "VSTs" (and then the appropriate entries); under Browse, the patch library.

[MuTools]

Glad you like it
A begginer or someone not familiarized with MU.LAB would indeed appreciate this grid stuff...IMHO i can't see why this is an extra gui complexity...it's so clean and simple...well it's up to you.

Sure, the 2nd mockup is nice, it nicely fits the existing structure. So that's good. With "extra complexity" i mean: there are 3 extra data items in the editor pane. Each extra data item adds requests more processing work from the left brain, especially when it's text. That's why i'm very careful with it. The other reason why i may postpone this is purely for time-table reasons. M3 must go towards release asap. I do give it the time to get finetuned, but i must draw a line some-where. Anyway, your idea certainly is on the list for further evaluation. Thanks!

Another thing: FILE, EDIT and HELP popup menus should really appear bellow the buttons...i think someone noted that it also happens everywhere (where it has buttons and menus).

100% agreed.

Practical point: We need updated buttons for the main menu, and some other places, as these buttons then need a 'down' state too. And i'm not sure if updating these graphic resources can be realized on short term.

If not, the menus-below-button thing may be put on the whishlist for later implementation.

[MuTools]

I shall do my usual wander by and throw something into the conversation then wander off without having actually been involved...

What if VST patches could be tagged and browsed in the library - i.e. you could tag a patch in a VST plugin as "bass" and it would appear under the "bass" folder and, when selected, load up the appropriate VST and select that patch?

That would put the VST plugins on the same level as the built-in synths and effects and on a separate branch from the patch library. So when you clicked to insert a plugin, you'd have "Create" and "Browse" as top level options; under Create, "Mu-Synths", "Mu-FX" and "VSTs" (and then the appropriate entries); under Browse, the patch library.

Logically yes, practically no, imho.

Because it takes too much time to unload/load VST plugs all the time.

[dwsel]

I like the approach to the in-module preset list -- the first time I was pretty surprised when I picked a different preset and the module itself changed because it's such unexpected behaviour. But I think that's just because we get used to conventions whether they are a smart way of doing things or not. Your way is smarter - at the end of the day, if you're looking to browse bass sounds, are you really bothered if it's module x or module y making the noise?

Being able to use VST presets in this way would be an awesome feature. I don't know about anyone else, but I'd use this a hell of a lot.

0.02 from an user
Yes, I can imagine this as a library looking like a open/save dialog:

+ means expandable
- means here preset - calling plugin or plugin itself

Code: Select all

LIBRARY (Title)

+ Effects
    + Presets (by default only MUX effects)
          + Ambience
               - MUX:delay1
               - MUX:delay2
               - MUX:reverb1

          + EQ
               - MUX:lowpass
               - MUX:highpass
               - VST_PLUGIN_NAME1:lowpass

          - VST_PLUGIN_NAME2:my favourite preset


    - MUX (opening MUX clean preset in editor mode)

    + VST
          - plugin1
          - plugin2 (alphabetically)

+ Istruments

    + Presets (by default only those using MU.LAB instruments)
          + Bass
               - Sampla:deepbass1
               - Synthia:boom

          + Pad
               - AVST_PLUGIN_NAME1:Warm
               - Synthia: Quiet

          - VST_PLUGIN_NAME2:my favourite preset

    + MU.LAB
          - musynth (opening synth with default preset)
          - synthia
          - sampla
          - multisampla

    + VSTI
          - plugin1
          - plugin2 (alphabetically)

By default only MU.LAB presets would be in library. Could you just imagine loading 300 presets from VST plugins without any category or clear name. Pretty much useless, isn't it?

Presets should be sorted by name, but the name should consist name of the plugin (or information that plugin is not available) to avoid confusing users, when the plugin changes to i.e. very CPU heavy (taking some seconds to load) or unavailable one generating error

User should be able to save/load/delete his presets (for VST plugs and for MU.LAB synths/effects) inside whole preset 'directory' (also outside the 'Bass' and 'Pad' categories) as well as manage categories. Positive thing is that preset structure could be stored in such a same tree on the hard drive and direct adding presets to hard drive could be reflected to the main Library (refreshed on MU.LAB startup and by refresh button not by every load as it would cause too much waiting). In these folder VST presets could be stored in typical *.fxp format with custom naming or accompanying MU.LAB settings file to keep preset file chained with name of VST dll. MU.LAB instrument and effect presets can have their own format to be easily exchanged between MU.LABers.

Vst plugins have also patch/bank loading from hard drive option. For traditional use (as it is currently). I find this option useful and I think other would appreciate leaving it too.


Just my idea, for clear look that would be loved by traditionalists (they would use VST with patches/banks loaded from hard drive and MUX/MU.LAB instruments with default patch), as well as 'librarians' - having their presets 'on top' [/code]

[sorohanro]

So what's missing in MU.LAB's sequence editor to make it heaven for you?

There are several things, maybe I got used to the thinking way in FL.
In the velocity & stuff windows, hen you left click = you change the particular note you clicked, when you right click = line tool that affect selected notes.

You mean the line tool for drawing velocity beams in the sequence editor?

Yep, that I can't find.

Also, I record something with my keyboard and while recording it works just fine. After I record, the track stays grey and whatever I do, I just can't link it to the device I recorded it with ...

[Calum]

Practical point: We need updated buttons for the main menu, and some other places, as these buttons then need a 'down' state too. And i'm not sure if updating these graphic resources can be realized on short term.

If not, the menus-below-button thing may be put on the whishlist for later implementation.

Jo
Just let me know if there is anything I can do to help with this. My Mac packed in late December so I have been out of circulation until now (New Mac arrived this week and is is just about up and running). Almost lost all the master files for LooxPhat in the process but I finally managed to rescue them from a dying hard drive! I should be able to spare some time to work on the skin towards the end of next week if you need any input from me. Happy to give feedback on M3 as well.

[pljones]

...

That's pretty much what I was thinking.

But I can see Jo's point about VSTs taking an unpredictable amount of time to load and needing to be unloaded to free up their resources -- as there's an unknown number of them wanting an unknown amount of resource!

However, I think there would be a benefit to integrating the VST patch system like this -- same argument as previously: "Oh, I created a bass patch... now, where is it... Oh, yes, under 'bass'" rather than "... Oh um, and uh, which synth did I use... urr..."