hey ok, the two pixels soultion is fair enough. i mean it solves it, cool. coz i really need the start menu.
about the open dialog at mulab startup, i like it. coz in most cases it speeds things up. and it gives the program more personality. and it can make u work more on a song even when u give up a little and want to jump on something new, lol.
and
@pljones
yeah, videos are fun!
MU.LAB 2.0 PreRelease
-
infectedpimple infectedpimple https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=182988
- KVRist
- 103 posts since 17 Jun, 2008 from Michigan
Jo,
Sorry for the late reply, about the window/taskbar grievance, and I find using PreRel D more comfortable in that regard. I did forget to mention that I did indeed already have the option enabled to keep the taskbar above other windows, but it seems others have chimed in and a decent compromise was found. I think part of the problem was maybe a confusion of the terms being used, at least insofar as Windows is concerned; as I've always understood it, to "maximize" a window would be to extend the frame of the window to the edge of the screen while making the window non-resizable (because if you pressed the maximize button, it's assumed you want it maximized, right?, but otherwise retaining the basic functionality and behaviours (such as keeping it beneath the taskbar) and aesthetics of the common floating window. "Full Screen" on the other hand, such as that employed by IE and Mozilla Firefox for instance, removes much and sometimes even all of the window gui (ie, the minimize/maximize/close button, menus, etc.) and cover over the taskbar even when otherwise the taskbar would remain on top of other windows, making it, more accurately termed I think, "full screen," suitable for presentations and such where you wouldn't want the interface distracting from the content. Before, it seemed that Mu.lab was trying more to be "full screen" than "maximized." But even now, in that sense, it still seems to me Mu.Lab isn't quite consistent, as "maximizing" the main window doesn't really maximize it the way other windows maximize; for one, you can still resize the window, which doesn't make sense to me, because in order to achieve this, you've made it so the window really isn't maximized, but rather only as if the user manually resized the edges of the window to the edge of the screen. Additionally, in Windows, the maximize button actually serves as a restore button as well, which returns the window to the size and position of the window before it was maximized, a feature I do find useful more often than not. Mu.Lab strips that functionality, though. It's certainly not the end of the world--it's just that one of the things a new user who is used to the conventions of Windows would probably notice first, rather than all the cool stuff going on in Mu.Lab, is that Mu.Lab's windows behave differently from the windows they are used to using, and so makes it less transparent from the user-side of things, to me at least.
As for my question/suggestion about extending the send options beyond simple gain, I'm just curious why you feel that having those options on the sends would be limiting or less "open?" You hope I see it the same way you do, but you didn't really explain to me why you think my suggestion would be limiting. So I'm still left thinking that yes, I can route those others ways, but my way would offer a simpler, faster solution in addition to those other ways. Having those options wouldn't bar people from routing through racks the way they are, uh, limited to now. After all, was it less "open" to include an integrated sampler in Mu.Lab when people could just get third party sampler to do pretty much the same thing? And did it bar people from using their preferred sampler plugin in Mu.Lab? If there is a technical reason behind your resistance to the idea, such as that it inherently adds too much latency to the signal or increases CPU overhead to undesirable levels, or that involves to many instances of the devil's number in the code to make work, I can understand that. But, as I said, sans an actual argument againt, to me it seems like it would be a very simple way to do common things with sends that otherwise involve more plugins and cpu overhead, not to mention more time spent setting up those plugins than actually acting on the creation at hand. More to the point, why even have a gain option then? Can't you route the send to another rack, adjust it through that racks gain slider, and then send that to a reverb or whatever? I just want you to clarify your thinking on that, since it seems to contradict something you've already implemented. And I still feel my suggestion at least has merit for further consideration--I really do like Mu.Lab a lot, but I would like it even more to have that option to simply delay or filter a send if I so wanted, in a manner that is streamlined, particularly at the point when I first load a send and the plugin interface is open anyhow. It just feels it would make things, at the risk of being redundant, easier, and flow more creatively for me. And ultimately, isn't that still your philosophy with Mu.Lab, to make things easier for the new/amateur user, more conducive to their creativity, while keeping things more "open" for the exerienced and professionals out there who might have their own preferences for getting things done? I know I'm being perhaps overly persistent about this, and it does not come without the understanding that you have lots on your plate, but I would be grateful to be convinced with an actual explanation as to why you feel it would introduce further limitation to Mu.lab, at which point I could happily drop it and not be further bothered about it, having been enlightened as to why precisely such send options would put me at the great risk of being "limited." Otherwise it gives the impression that you haven't really thought about it at all, and dismissed the suggestion purely on the basis of your own bias, or worse perhaps that it's just a kind of creative laziness. Mind, Jo, I don't intend that in any way except in the sincere spirit of constructive criticism, as a fellow maker of things who sometimes (often) needs to be reminded of his own biases and/or laziness that affects adversely the quality of his creative output. And I'd like to tend toward you're having a logical progression of thought on this matter, from your unique position as developer that, if offered, would help me see the situation as you do. I do hope you can humor me on that, it'd be greatly appreciated. And again, best of luck on your further development, may the music gods shine their glorious light upon Mu.Lab!
my best,
- j
Sorry for the late reply, about the window/taskbar grievance, and I find using PreRel D more comfortable in that regard. I did forget to mention that I did indeed already have the option enabled to keep the taskbar above other windows, but it seems others have chimed in and a decent compromise was found. I think part of the problem was maybe a confusion of the terms being used, at least insofar as Windows is concerned; as I've always understood it, to "maximize" a window would be to extend the frame of the window to the edge of the screen while making the window non-resizable (because if you pressed the maximize button, it's assumed you want it maximized, right?, but otherwise retaining the basic functionality and behaviours (such as keeping it beneath the taskbar) and aesthetics of the common floating window. "Full Screen" on the other hand, such as that employed by IE and Mozilla Firefox for instance, removes much and sometimes even all of the window gui (ie, the minimize/maximize/close button, menus, etc.) and cover over the taskbar even when otherwise the taskbar would remain on top of other windows, making it, more accurately termed I think, "full screen," suitable for presentations and such where you wouldn't want the interface distracting from the content. Before, it seemed that Mu.lab was trying more to be "full screen" than "maximized." But even now, in that sense, it still seems to me Mu.Lab isn't quite consistent, as "maximizing" the main window doesn't really maximize it the way other windows maximize; for one, you can still resize the window, which doesn't make sense to me, because in order to achieve this, you've made it so the window really isn't maximized, but rather only as if the user manually resized the edges of the window to the edge of the screen. Additionally, in Windows, the maximize button actually serves as a restore button as well, which returns the window to the size and position of the window before it was maximized, a feature I do find useful more often than not. Mu.Lab strips that functionality, though. It's certainly not the end of the world--it's just that one of the things a new user who is used to the conventions of Windows would probably notice first, rather than all the cool stuff going on in Mu.Lab, is that Mu.Lab's windows behave differently from the windows they are used to using, and so makes it less transparent from the user-side of things, to me at least.
As for my question/suggestion about extending the send options beyond simple gain, I'm just curious why you feel that having those options on the sends would be limiting or less "open?" You hope I see it the same way you do, but you didn't really explain to me why you think my suggestion would be limiting. So I'm still left thinking that yes, I can route those others ways, but my way would offer a simpler, faster solution in addition to those other ways. Having those options wouldn't bar people from routing through racks the way they are, uh, limited to now. After all, was it less "open" to include an integrated sampler in Mu.Lab when people could just get third party sampler to do pretty much the same thing? And did it bar people from using their preferred sampler plugin in Mu.Lab? If there is a technical reason behind your resistance to the idea, such as that it inherently adds too much latency to the signal or increases CPU overhead to undesirable levels, or that involves to many instances of the devil's number in the code to make work, I can understand that. But, as I said, sans an actual argument againt, to me it seems like it would be a very simple way to do common things with sends that otherwise involve more plugins and cpu overhead, not to mention more time spent setting up those plugins than actually acting on the creation at hand. More to the point, why even have a gain option then? Can't you route the send to another rack, adjust it through that racks gain slider, and then send that to a reverb or whatever? I just want you to clarify your thinking on that, since it seems to contradict something you've already implemented. And I still feel my suggestion at least has merit for further consideration--I really do like Mu.Lab a lot, but I would like it even more to have that option to simply delay or filter a send if I so wanted, in a manner that is streamlined, particularly at the point when I first load a send and the plugin interface is open anyhow. It just feels it would make things, at the risk of being redundant, easier, and flow more creatively for me. And ultimately, isn't that still your philosophy with Mu.Lab, to make things easier for the new/amateur user, more conducive to their creativity, while keeping things more "open" for the exerienced and professionals out there who might have their own preferences for getting things done? I know I'm being perhaps overly persistent about this, and it does not come without the understanding that you have lots on your plate, but I would be grateful to be convinced with an actual explanation as to why you feel it would introduce further limitation to Mu.lab, at which point I could happily drop it and not be further bothered about it, having been enlightened as to why precisely such send options would put me at the great risk of being "limited." Otherwise it gives the impression that you haven't really thought about it at all, and dismissed the suggestion purely on the basis of your own bias, or worse perhaps that it's just a kind of creative laziness. Mind, Jo, I don't intend that in any way except in the sincere spirit of constructive criticism, as a fellow maker of things who sometimes (often) needs to be reminded of his own biases and/or laziness that affects adversely the quality of his creative output. And I'd like to tend toward you're having a logical progression of thought on this matter, from your unique position as developer that, if offered, would help me see the situation as you do. I do hope you can humor me on that, it'd be greatly appreciated. And again, best of luck on your further development, may the music gods shine their glorious light upon Mu.Lab!
my best,
- j
-
- KVRAF
- Topic Starter
- 13862 posts since 24 Jun, 2008 from Europe
Indeed, but i don't think that's a problem.infectedpimple wrote:But even now, in that sense, it still seems to me Mu.Lab isn't quite consistent, as "maximizing" the main window doesn't really maximize it the way other windows maximize;
Because the borders are so thin that they don't waste screen space.
And as they are still there, they're still functional too
It's a little bit different from the 'standard' on that point, yes, but i'm ok with it.
Windows windows are not 'perfect' either. How many times did i already scream it out when explorer or whatever window didn't open in their size as i lastly sized it. Grrr.
This point i can understand.Additionally, in Windows, the maximize button actually serves as a restore button as well, which returns the window to the size and position of the window before it was maximized, a feature I do find useful more often than not.
Will add a note on the whishlist.
The main reason is:As for my question/suggestion about extending the send options beyond simple gain, I'm just curious why you feel that having those options on the sends would be limiting or less "open?" You hope I see it the same way you do, but you didn't really explain to me why you think my suggestion would be limiting.
Today, you would like to have a delay built-in in the send, tomorrow someone else wants to have an EQ built-in in the send, day after tomorrow someone wants MUX there...
It's much better for everyone to keep the architecture simple and flexible.
The way it is now, you can insert whatever in the send path!
And that's the way it should be, imho.
Hope you see what i mean.
Indeed, it wouldn't make it less open, but it would make it more bloated (both on technical level as on user level). And that's not good.Having those options wouldn't bar people from routing through racks the way they are, uh, limited to now.
The main reasons for this 'resistance' are:If there is a technical reason behind your resistance to the idea, such as that it inherently adds too much latency to the signal or increases CPU overhead to undesirable levels, or that involves to many instances of the devil's number in the code to make work, I can understand that.
-> Proper modularity as well on the user side, as well on the technical side
-> What you want IS already possible, even in a simple, straightforward way
-> In fact, MU.LAB targets a broad range of people, not essentially advanced users only
-> There is a lot on the whishlist, other FRs definitely have higher priority
That's theoretically a true argument, i agree.More to the point, why even have a gain option then? Can't you route the send to another rack, adjust it through that racks gain slider, and then send that to a reverb or whatever?
But practically the "send gain" is a parameter that is essential for a send. Look at mixing consoles: they all have a send gain. But do they have an integrated send delay?
Again, i think your musical request to have a delay in the send path is perfectly making sense.
And it is realizable in a simple and straightforward way.
But hard-coding it in the signal path is not the plan for the reasons mentioned above.
Hope this answers your questions.