just upgraded to 8 ..... MUX MUX MUX !!!About the next MuLab 9
-
- KVRAF
- 2270 posts since 30 Aug, 2004 from Lancaster, UK
Great to hear about MuLab 9 being announced. 
It seems MuLab has two user groups, tweakers and more regular DAW users who just enjoy a fast workflow. I’m using MuLab mainly in an oldschool way, as a sequencer, enjoying the superior workflow of this DAW. Every now and again I try other DAWs (say, to hook up Melodyne through ARA), but boy what a relief to go back to MuLab.
In other words, for my own music, I’m less interested in automating stuff in explorative ways.
Perhaps unintentionally, this thread turned into an FR list, so here are my thoughts – cranked up to 11 it seems. To stay constructive, these are mainly on matters already addressed in the thread, and in any way based on my use cases.
I appreciate that some or all of these ideas may have no merit whatsoever, I don’t want to start a debate, and I don't expect feedback on them; I just share them in case they can improve MuLab/MUX even more, and maybe make dev time more fun at the same time.
1. VST3/ARA2/WaveShell: Keeping up with standards is obviously troublesome for a one-man company. Moreover, except for connectivity, they don’t bring any extra features in themselves. What I’m thinking is that instead of putting in, say, 18 months’ work on such matters, and then having to redo it as these standards progress and new appear, why not work with one of the wrapper dev’s? I installed Kushview’s Element (freeware) yesterday and suddenly I can run Waves software, AAX and probably more things inside MuLab. It works without a glitch.
I’m thinking that the chosen wrapper wouldn’t have to show up, but instead work behind the scenes. Then, as an option (like a button in the VSTi’s top menu (=MUX) bar), the wrapper itself could be shown, allowing for other intricacies. Maybe this is not ideal, but it can – perhaps – be a great time saver when it comes to development. And more importantly, with the right choice of built-in wrapper, MuLab (and maybe MUX) would be future-proofed as well. Besides, MuLab is rock solid in its current state, and writing code to talk to other standards can maybe mess things up and cause instability under certain circumstances.
Not sure this can work, but if it can, it could be a game-changer.
Having worked as a software developer, I think it would be more fun to develop new code for new features than work with interpreting standards. Having fun at work is an important theme, especially in the music software industry as we programmers can all get better pay in other places.
2. MPE support: Perhaps. It certainly goes to cred, but at the same time I’m not sure it would be used by many of MuLab’s users, or if it would attract new ones. I just don’t know, but I’d prefer development time spent on whatever people would actually use. (And as stated in another thread, MPE support per se may not be necessary, as other standards may well be able to cover this feature.)
3. Notation support: don’t go there. It’s a nightmare to implement and has very little to do with the fan base (or so I presume).
4. I too miss the highlighted keys in the keyroll editor. I figure this limitation must have to do with the GUI framework, and that it can’t easily be overcome. A probably easy alternative, as well as a feature in itself, is Snap to scale. I assume 95 per cent of all MuLab users work in major or minor scales. The programming logic for Snap to scale could be written on a napkin, so I guess it may not be so difficult to implement it. …and as a consequence, we wouldn’t have to look as closely at the keyboard to the editor’s left, lessen the need for the highlighted keys.
5. While I’m at it, I don’t think there’s a value saying how much we drag selected notes upwards or downwards in the keyroll editor. It’s typically in the bottom part of the editor window. I usually change octaves of my sequenced parts (or drag them a fifth), and then, it would be handy to see, say, “7” or “-12”.
6. Not sure if this is difficult to implement, but if not, then I’d appreciate if the main window could scroll when I ctrl-drag parts to duplicate them (it helps when building the arrangement). …but I get that this might be problematic due to how the GUI framework works.
6. Really happy to hear that side-chaining is planned to become a one- or two-click process! Can't wait to find out how it will actually work.
7. A week back or two, I asked on help for how to do a ducker in MUX. A universal ducker MUX (or like functionality as part of the arranger window) would be a nifty feature. Perhaps GUI-wise placed next to the side-chain functionality, as they are quite related.
8. On the same note, I haven’t brought up the Freeze FR in a while (or maybe I have). I understand the “purists’” argument that Freeze would disable some functionality when another module is controlling a certain track etc, but then again, isn’t that sort of the definition of Freeze? I mean, if I out some water colour paint in a glass of water, the water gets coloured throughout. If I put paint on an ice cube, it won’t. So, in my world, this is the same thing as a Sound Recorder MUX, put in a rack directly after the synth, and then muting the synth, but done in one right-click.
I’m not so interested in this feature to save CPU – today’s computers are that strong. Instead, I want it to freeze the output of my granular synths, as this output varies between “takes”. …and preferably without the need of workarounds, like recording to other tracks etc.
9. One matter, which I haven’t brought up in a few years I think, but to me it seems more relevant since the release of MUX 8. I enjoy building MUXes, and I’ve uploaded a few of them in the library. With MUX 8, Jo gave us the ability to create beautiful front panels. Thus, we now have the ability to create great-sounding, great-looking instruments and effects that are super easy on the CPU. Still, not many are uploaded in the library, and the last one in April, if I'm not mistaken. I assume many of the “MUXeteers” are, like myself, happy when people download and use their stuff – after all, why else do minute changes to GUIs for example?
Thus: I think another game-changer would be MUX -> VSTi export. Flood KVR with MUXes (in the form of VSTis)! I don’t care about getting paid for them, I’d just like the opportunity to share them. I think this could bring in many, many users to MuLab/MUX (MUXLab? – no that sounds terrible, doesn’t it
). ..and if this doesn’t work for technical reasons, then possibly the MUX player we’ve been discussing way back would be an option, but this would be much cooler.
Perhaps there could be a QA committee here in the community (Michael L, Dakkra, pjones etc) so that only usable, good-looking and good-sounding MUX-based VSTis can be uploaded to KVR, to protect the brand.
So basically a successor to SynthEdit, but based on the joy of sharing (much like people upload images of their MineCraft models). To my knowledge, there exists very few frameworks like this today. Perhaps this would be difficult to implement though. I don't know since I don't know how the formats/APIs correlate.
10. Making one package only of MUX/Mulab – well, I think it’s a matter of how many are just interested in MUX (as they’d need to pay for a DAW they might not use as their main DAW (can’t think of a reason for that though)). FYI, this is how EnergyXT worked. Jorgen sort of hid that feature a bit in eXT2, but in v1, the first thing one needed to do was to insert a sequencer module. If nothing else, it was a bit quirky and kinda fun. (I haven’t used Muzys, so I don’t know how this worked there.)
11. Regarding pricing, I agree with someone mentioning it’s probably best to stick to the current price model (or as someone else mentioned, use Reaper’s, but I wonder if not that would give quite much support hassle for Jo). A one-time payment, with a discount for existing users, seems to me like problems on the horizon regarding working capital and cash flow.
I love MuLab, so personally I’m up for any solution.
Well, those are my thoughts! For now, best of luck with finalising MuLab 9 and MUX 9! 
It seems MuLab has two user groups, tweakers and more regular DAW users who just enjoy a fast workflow. I’m using MuLab mainly in an oldschool way, as a sequencer, enjoying the superior workflow of this DAW. Every now and again I try other DAWs (say, to hook up Melodyne through ARA), but boy what a relief to go back to MuLab.
In other words, for my own music, I’m less interested in automating stuff in explorative ways.Perhaps unintentionally, this thread turned into an FR list, so here are my thoughts – cranked up to 11 it seems. To stay constructive, these are mainly on matters already addressed in the thread, and in any way based on my use cases.
I appreciate that some or all of these ideas may have no merit whatsoever, I don’t want to start a debate, and I don't expect feedback on them; I just share them in case they can improve MuLab/MUX even more, and maybe make dev time more fun at the same time.
1. VST3/ARA2/WaveShell: Keeping up with standards is obviously troublesome for a one-man company. Moreover, except for connectivity, they don’t bring any extra features in themselves. What I’m thinking is that instead of putting in, say, 18 months’ work on such matters, and then having to redo it as these standards progress and new appear, why not work with one of the wrapper dev’s? I installed Kushview’s Element (freeware) yesterday and suddenly I can run Waves software, AAX and probably more things inside MuLab. It works without a glitch.
I’m thinking that the chosen wrapper wouldn’t have to show up, but instead work behind the scenes. Then, as an option (like a button in the VSTi’s top menu (=MUX) bar), the wrapper itself could be shown, allowing for other intricacies. Maybe this is not ideal, but it can – perhaps – be a great time saver when it comes to development. And more importantly, with the right choice of built-in wrapper, MuLab (and maybe MUX) would be future-proofed as well. Besides, MuLab is rock solid in its current state
, and writing code to talk to other standards can maybe mess things up and cause instability under certain circumstances.Not sure this can work, but if it can, it could be a game-changer.
Having worked as a software developer, I think it would be more fun to develop new code for new features than work with interpreting standards. Having fun at work is an important theme, especially in the music software industry as we programmers can all get better pay in other places.
2. MPE support: Perhaps. It certainly goes to cred, but at the same time I’m not sure it would be used by many of MuLab’s users, or if it would attract new ones. I just don’t know, but I’d prefer development time spent on whatever people would actually use. (And as stated in another thread, MPE support per se may not be necessary, as other standards may well be able to cover this feature.)
3. Notation support: don’t go there. It’s a nightmare to implement and has very little to do with the fan base (or so I presume).
4. I too miss the highlighted keys in the keyroll editor. I figure this limitation must have to do with the GUI framework, and that it can’t easily be overcome. A probably easy alternative, as well as a feature in itself, is Snap to scale. I assume 95 per cent of all MuLab users work in major or minor scales. The programming logic for Snap to scale could be written on a napkin, so I guess it may not be so difficult to implement it. …and as a consequence, we wouldn’t have to look as closely at the keyboard to the editor’s left, lessen the need for the highlighted keys.
5. While I’m at it, I don’t think there’s a value saying how much we drag selected notes upwards or downwards in the keyroll editor. It’s typically in the bottom part of the editor window. I usually change octaves of my sequenced parts (or drag them a fifth), and then, it would be handy to see, say, “7” or “-12”.
6. Not sure if this is difficult to implement, but if not, then I’d appreciate if the main window could scroll when I ctrl-drag parts to duplicate them (it helps when building the arrangement). …but I get that this might be problematic due to how the GUI framework works.
6. Really happy to hear that side-chaining is planned to become a one- or two-click process! Can't wait to find out how it will actually work.
7. A week back or two, I asked on help for how to do a ducker in MUX. A universal ducker MUX (or like functionality as part of the arranger window) would be a nifty feature. Perhaps GUI-wise placed next to the side-chain functionality, as they are quite related.
8. On the same note, I haven’t brought up the Freeze FR in a while (or maybe I have
). I understand the “purists’” argument that Freeze would disable some functionality when another module is controlling a certain track etc, but then again, isn’t that sort of the definition of Freeze? I mean, if I out some water colour paint in a glass of water, the water gets coloured throughout. If I put paint on an ice cube, it won’t. So, in my world, this is the same thing as a Sound Recorder MUX, put in a rack directly after the synth, and then muting the synth, but done in one right-click.I’m not so interested in this feature to save CPU – today’s computers are that strong. Instead, I want it to freeze the output of my granular synths, as this output varies between “takes”. …and preferably without the need of workarounds, like recording to other tracks etc.
9. One matter, which I haven’t brought up in a few years I think, but to me it seems more relevant since the release of MUX 8. I enjoy building MUXes, and I’ve uploaded a few of them in the library. With MUX 8, Jo gave us the ability to create beautiful front panels. Thus, we now have the ability to create great-sounding, great-looking instruments and effects that are super easy on the CPU. Still, not many are uploaded in the library, and the last one in April, if I'm not mistaken. I assume many of the “MUXeteers” are, like myself, happy when people download and use their stuff – after all, why else do minute changes to GUIs for example?
Thus: I think another game-changer would be MUX -> VSTi export. Flood KVR with MUXes (in the form of VSTis)! I don’t care about getting paid for them, I’d just like the opportunity to share them. I think this could bring in many, many users to MuLab/MUX (MUXLab? – no that sounds terrible, doesn’t it
). ..and if this doesn’t work for technical reasons, then possibly the MUX player we’ve been discussing way back would be an option, but this would be much cooler.Perhaps there could be a QA committee here in the community (Michael L, Dakkra, pjones etc) so that only usable, good-looking and good-sounding MUX-based VSTis can be uploaded to KVR, to protect the brand.
So basically a successor to SynthEdit, but based on the joy of sharing (much like people upload images of their MineCraft models). To my knowledge, there exists very few frameworks like this today. Perhaps this would be difficult to implement though. I don't know since I don't know how the formats/APIs correlate.
10. Making one package only of MUX/Mulab – well, I think it’s a matter of how many are just interested in MUX (as they’d need to pay for a DAW they might not use as their main DAW (can’t think of a reason for that though
)). FYI, this is how EnergyXT worked. Jorgen sort of hid that feature a bit in eXT2, but in v1, the first thing one needed to do was to insert a sequencer module. If nothing else, it was a bit quirky and kinda fun. (I haven’t used Muzys, so I don’t know how this worked there.) 11. Regarding pricing, I agree with someone mentioning it’s probably best to stick to the current price model (or as someone else mentioned, use Reaper’s, but I wonder if not that would give quite much support hassle for Jo). A one-time payment, with a discount for existing users, seems to me like problems on the horizon regarding working capital and cash flow.
I love MuLab, so personally I’m up for any solution.
Well, those are my thoughts! For now, best of luck with finalising MuLab 9 and MUX 9!
Thu Oct 01, 2020 1:15 pm Passing Bye wrote:
"look at SparkySpark's post 4 posts up, let that sink in for a moment"
Go MuLab!
"look at SparkySpark's post 4 posts up, let that sink in for a moment"
Go MuLab!
-
- KVRAF
- Topic Starter
- 13863 posts since 24 Jun, 2008 from Europe
-
- KVRAF
- Topic Starter
- 13863 posts since 24 Jun, 2008 from Europe
It also depends on the root key, right?SparkySpark wrote: Thu Oct 01, 2020 11:36 am 4. I too miss the highlighted keys in the keyroll editor. A probably easy alternative, as well as a feature in itself, is Snap to scale. I assume 95 per cent of all MuLab users work in major or minor scales. The programming logic for Snap to scale could be written on a napkin, so I guess it may not be so difficult to implement it.
So there are 2 important parameters: Root key and scale.
The key lanes also have a subtle shading that reflects the piano keys so you don't have to look at the left. If you want more contrast see the "Piano Key Lanes Contrast" preference.…and as a consequence, we wouldn’t have to look as closely at the keyboard to the editor’s left, lessen the need for the highlighted keys.
-
- KVRAF
- 2270 posts since 30 Aug, 2004 from Lancaster, UK
Thanks for replying! I know you must be incredibly busy now.mutools wrote: Mon Oct 05, 2020 12:02 pmIt also depends on the root key, right?SparkySpark wrote: Thu Oct 01, 2020 11:36 am 4. I too miss the highlighted keys in the keyroll editor. A probably easy alternative, as well as a feature in itself, is Snap to scale. I assume 95 per cent of all MuLab users work in major or minor scales. The programming logic for Snap to scale could be written on a napkin, so I guess it may not be so difficult to implement it.
So there are 2 important parameters: Root key and scale.
The key lanes also have a subtle shading that reflects the piano keys so you don't have to look at the left. If you want more contrast see the "Piano Key Lanes Contrast" preference.…and as a consequence, we wouldn’t have to look as closely at the keyboard to the editor’s left, lessen the need for the highlighted keys.
Yes, I use the shading. Still, I constantly drag "notes" to the wrong key lane. I assume that is why the other poster asked for visual feedback on the keyboard. Of course, it's not a biggie anyway.
Root key and scale? No I don't think that is the case. Let me explain what I mean.
Use case 1: I choose Am for my song. (I assume there will be no need for multiple key signatures; if so, a user can simply change the key when working in another key, let's say the final chorus of a Eurovision pop song
).Now, as I drag a note, it snaps to white keys only (as it's Am). It does this regardless of octave. So it has nothing to do with if I have a sequence of, let's say, Am - Dm - F - G. They are all "white key" chords.
Use case 2: I choose C Major for my song. The same sequence would apply also there, so in this case it would be the same result.
There are a few variations of minor (it mainly has to do with the seventh). The one noted above, is to my knowledge, only found in pop music. I think that for MuLab's audience, this option would go a very long way, and make the snappiest DAW key editor even snappier.
Of course, this functionality could be expanded upon, to include chord analysis etc, but I think that's simply too much and of too little value for most of us to bother about and spend time on.So, just to be clear: like snapping to the nearest 16th note position or so when moving stuff around, but on the y axis, based on major and (pop) minor scales.
I am pretty sure this would make moving notes easier and lessen the need for visual feedback on the left-side piano, as 5/12 of the keys would simply not be available. (Obviously, there must be a way to temporarily disable snapping. One way, sort of a workaround, would be to select the note and do it manually in the note height textbox. An option would be to alt-click or so, but perhaps all optional keys are taken.)
Thu Oct 01, 2020 1:15 pm Passing Bye wrote:
"look at SparkySpark's post 4 posts up, let that sink in for a moment"
Go MuLab!
"look at SparkySpark's post 4 posts up, let that sink in for a moment"
Go MuLab!
-
- KVRAF
- 5381 posts since 25 Jan, 2014 from The End of The World as We Knowit
This raises an important question: what should music software do, what should the musician do, and what does the musician lose and gain when software does what the musician could do?
F E E D
Y O U R
F L O W
Y O U R
F L O W
-
- KVRAF
- Topic Starter
- 13863 posts since 24 Jun, 2008 from Europe
Well that's 2 important aspects: It's A (=root key) and it's minor (=scale).
That's a strong assumption you make. I assume i will not make that assumption.I assume there will be no need for multiple key signatures
"simply"?if so, a user can simply change the key when working in another key, let's say the final chorus of a Eurovision pop song
Assuming that it should be possible to change root key and scale at any point in a composition, then there should be proper ways how to handle that.
I agree it definitely is an interesting topic and in fact the topic is on the wishlist for M29 (maybe earlier
) But my point here is that it's not as simple as a single key-scale for all parts. Also drum parts should be excluded etc.-
- KVRAF
- 2270 posts since 30 Aug, 2004 from Lancaster, UK
Thanks! I just sent a msg regarding this to infodesk, to keep the thread clean.mutools wrote: Tue Oct 06, 2020 7:15 pm I agree it definitely is an interesting topic and in fact the topic is on the wishlist for M29 (maybe earlier
Thu Oct 01, 2020 1:15 pm Passing Bye wrote:
"look at SparkySpark's post 4 posts up, let that sink in for a moment"
Go MuLab!
"look at SparkySpark's post 4 posts up, let that sink in for a moment"
Go MuLab!
-
- KVRAF
- Topic Starter
- 13863 posts since 24 Jun, 2008 from Europe
-
Suono & Computer Suono & Computer https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=388513 - KVRist
- 99 posts since 14 Nov, 2016 from Italy
Good question, well let's say that the software could give some stimulus by generating harmonies, sounds or patterns in a random way so that the musician has a stimulus to create and arrange a song better ... Starting from scratch is sometimes very frustrating for those who do not has concrete ideas ... For example, I tried some generative music online software and they stimulated me a lot, even if only to create "the environment" or "the general idea of the musical genre itself" ... then yes can remove, add, change ... For those like me who are fond of ambient or generative music, help from the machine is happy ... After that it's just my opinion ... Audio) helped me a lot to start with a phrasing or a small theme ... then you slow down the tempo, change the notes ... the sounds ... you can do everything ...Michael L wrote: Tue Oct 06, 2020 6:33 pm This raises an important question: what should music software do, what should the musician do, and what does the musician lose and gain when software does what the musician could do?
-
- KVRian
- 703 posts since 15 Sep, 2003
A modular clip launching grid ala Abelton (or old school Project 5), or like the NORA vst grid, perhaps? MuGrid? That would be sweet!mutools wrote: Tue Jul 07, 2020 12:00 pm MuLab 9 is in the making and one of the most prominent new features will be flexible clip launching!
"Music is directly tied to the technology of a culture."
"Modular gear is the craft beer of music."
"Modular gear is the craft beer of music."
-
- KVRist
- 139 posts since 15 Dec, 2014
Hi Jo, I hope everything is going well. I have a MUX7 licence (I've been out of the loop for while) and it's time for an upgrade, should I wait for MUX9? How might the various upgrade options change? (Sorry to even ask, I would prefer to just upgrade every version but this year has been a disaster.)
-
- KVRAF
- Topic Starter
- 13863 posts since 24 Jun, 2008 from Europe
I cannot yet answer that question atm but will do my best to take decission on short term.