I have to open a VST for it to work - what's going on?

[johnjaypl]

Because of the problems I'm having with the mulab modules "amplifier" and "ADSR Envelope" I downloaded an envelope VST off the net. It's called envy. It's not exactly what I wanted but it does seem to work except I have the following problems with it.

1) Envy is burried in a MUX but it doesn't work until I go into the mux with deep edit and open it up. Then all is fine.

2) Worse than that I don't get any sound when I mix down. I imagine the problem is something similar to what's causing 1) but of course I don't really know what the problem is.

I've never had this problem with other VSTs so I suppose it could be and "envy" problem. Could it also be a MU.LAB problem? Any ideas about why "envy" would need to be opened before it worked?

John

[johnjaypl]

I tried a few more ADSR VSTs and eventually found one that works with MU.LAB during mixddown. So unless Mutools is interested in pursuing this I'll drop it and move on. (I personally think Mutools should be pursuing these kinds of things even though it could very well be the fault of the plugin because that's how you end up with a "rock solid" product.)

John

[MuTools]

John, 2 considerations:

1) I cannot track every single VST. This would mean a fulltime job on its own and would mean that MU.LAB itself stops evolving. I'm confident MU.LAB 3's VST engine is 99% ok. (FYI: no host reaches 100%) If there is a clear indication that MU.LAB 3 does something wrong, VST-wise, please let me know, but it must be clear and wel defined, as i must manage the available time, and the available time is limited. Hope you understand.

2) M3 is about to be released and besides fixing explicit bugs, i will take a pause, for multiple reasons. Believe me (or not), this is best for the whole project.

I really hope many musicians will find M3 a good musical tool, which supports and maybe even inspires musical creativity. If not, i'll take logical conclusions. Otherwise, i'll be eager to R&D M4! Cheers!

[johnjaypl]

John, 2 considerations:

1) I cannot track every single VST. This would mean a fulltime job on its own and would mean that MU.LAB itself stops evolving. I'm confident MU.LAB 3's VST engine is 99% ok. (FYI: no host reaches 100%) If there is a clear indication that MU.LAB 3 does something wrong, VST-wise, please let me know, but it must be clear and wel defined, as i must manage the available time, and the available time is limited. Hope you understand.

2) M3 is about to be released and besides fixing explicit bugs, i will take a pause, for multiple reasons. Believe me (or not), this is best for the whole project.

I really hope many musicians will find M3 a good musical tool, which supports and maybe even inspires musical creativity. If not, i'll take logical conclusions. Otherwise, i'll be eager to R&D M4! Cheers!

I suspected you would say something like that and it may be understandable given your available resources. Unfortunetly, reality (the amount of effort it takes to really make a rock solid product) has no concern about your resource limitations. That is, it takes what it takes to get out all of the bugs in a product as complex as MU.LAB. And part of what it takes, in my experience is tracking down false alarms- because sometimes they're not false.

This particuliar case may not be worth tracking down and I have no special love for the VSTs that didn't play nice with MU.LAB but generally speaking I think MU.LAB needs to work less on new features and more on getting the quality up. That is, although I can think of a lot of good things to say about MU.LAB, it being "rock solid" isn't one of them.

John

[cytone]

[Nielzie]

I think MULAB is quite stable as a sequencer/DAW. I don't know a lot of software applications that are going through a closed beta stage for months, releasing 37 beta's where numerous thoroughly tested bugs where fixed (and where a "new feature freeze" had been taken place) before releasing it to final stage at last.

I don't have any issues or crashes anymore so I'm pretty happy with M3

[liquidsound]

although I can think of a lot of good things to say about MU.LAB, it being "rock solid" isn't one of them.
John

I would like to add, if I may, what is your DEFINITION of "ROCK SOLID".

And that goes for EVERYTHING that is going to be Plugged into ANYTHING ELSE.

This is why REASON is a closed box... and.. you pay for that, in cash and freedom...

[johnjaypl]

That kind of comment doesn't really help anything, now does it?

I think MULAB is quite stable as a sequencer/DAW. I don't know a lot of software applications that are going through a closed beta stage for months, releasing 37 beta's where numerous thoroughly tested bugs where fixed (and where a "new feature freeze" had been taken place) before releasing it to final stage at last.

I don't have any issues or crashes anymore so I'm pretty happy with M3

I still have crashes. I also have unexpected "random" behavior. For example- the mute problem that I posted about - and many others. It's not really about how many bugs you fix or how many releases you do, it's how many problems are left.

And then there's a class of "problems" where the designers didn't think or plan for anyone using a feature in a certain way even though all the hooks are there for it to be used that way and they didn't bother to document that it doesn't work that way either.

I can imagine that MU.LAB is fairly, but hardly "rock", solid if used in a certain way but once it's out of it's comfort zone it often fails.

I'm going to continue to give my feedback as I find issues. MUTOOLS can file my feedback as they see fit. I'm pretty sure that we both would like to see them same thing in the end. A great MU.LAB!

John

[pljones]

John, I think you're approaching MU.LAB from a different direction from many of its existing users and this means you're hitting use cases that (a) haven't been hit before and (b) haven't been thought of. (I'm not saying all MU.LAB users work the same way -- far from it. But I'm sure we've all learnt to avoid working certain ways when we've seem "strange things" happen and said nothing!)

The corollary is that you're uncovering unexpected behaviour. Which is a good thing! Even better, you're reporting it.

The other corollary is that the unexpected behaviour is undocumented - it's not been planned to work in that unexpected way, so expecting the documentation to explain it is unreasonable.

Unfortunately, you've joined the development cycle just before a major release. Some of the behaviour you're identifying presumably needs changes that would jeopardise that release by introducing a scale of change that would likely make the application less stable and more error prone. I'm sure had you been having these issues back when the development of MU.LAB 3.x started, many would be cleared.

Don't get put off by the fact the issues aren't being cleared right now. It's not because they're not important.

(Do I get the job in PR?)

[Nielzie]

I'm going to continue to give my feedback as I find issues. MUTOOLS can file my feedback as they see fit. I'm pretty sure that we both would like to see them same thing in the end. A great MU.LAB!

John

That's the spirit John, let us altogether get MU.LAB stable as a rock of pure granite

[liquidsound]

I am sorry John... but your comments do not sound sincere.... almost with a flavor of the competition... trying too hard....

If I am wrong then, I hope you have been going through this Beta section posts and then perhaps understand what an amazing process of evolution this DAW has been through in this short time with an impeccable dedication from the developer.

If you are new to Music software ( sounds like or refer to first paragraph) then you could have a rude awakening trying to find and use other product in all possible unintended/intended/sideway/alternate use of them.
Never mind read the manuals for all the above possible combinations...

You know what I mean...

I am not here to police anybody but it is quite disturbing to read comments that should evolve from a user maturity point of reference.

Anyway, welcome here and I hope you will develop a sensitivity and ability to see the strength of this magnificent small innovative DAW and his dedicated brilliant developer.

[MuTools]

I still have crashes. I also have unexpected "random" behavior. For example- the mute problem that I posted about - and many others.

The last thing you wrote about the mute problem is that you were not sure yourself whether there is/was a problem.

IF there is a problem, mute problem or anything else, please narrow it down on your side (i do assume you have the intelligence for that) so that the problem can be clearly repeated using a step-by-setp procedure, and share it so it can be researched. Thanks in advance.

And then there's a class of "problems" where the designers didn't think or plan for anyone using a feature in a certain way even though all the hooks are there for it to be used that way and they didn't bother to document that it doesn't work that way either.

"Not bothering" is a too loosy description, imho.

FYI: I'm not going to document everything MU.LAB does not. I even don't document everything MU.LAB does. The docs are a basic reference guide which should be enough so you can find everything. My own guidline is: the docs should describe everything the user cannot find on his/her own.

Again (and for the last time): I agree with you that the "bi-directional parameter mapping issue" (i.e. only applied on the GUI level) may be a confusing non-feature. I've been thinking that the best solution on short term would be to simply mute that bi-directionallity also on GUI level so there is no difference anymore. That's an option. But i'm not sure i'll go for it.

I also agreed (also for the last time) on the second issue, the "MIDI controller mapping" issue. Notes have been added to the whishlist.

(FYI: The reason that mulab's own plugs don't take cc from sequencing/patching (only from midi in) is because all parameters can be automated directly and i wanted to avoid a 'double' system, i.e. automation via cc and parameter direct, especially to spare the user from confusing situations. but i did not take into account that midi vsts can output cc and that it can be handy to use them towards mu plugs too. so lets call it an analysis mistake on my side. will most probably be improved in a future version but i'm unable to realize this on short term)

So about your "class of problems": Besides the above 2, i would appreciate that you explicitly and clearly describe all the other problems in the class.

I can imagine that MU.LAB is fairly, but hardly "rock", solid if used in a certain way but once it's out of it's comfort zone it often fails.

Please elaborate.

I'm going to continue to give my feedback as I find issues. MUTOOLS can file my feedback as they see fit. I'm pretty sure that we both would like to see them same thing in the end. A great MU.LAB!

[johnjaypl]

The last thing you wrote about the mute problem is that you were not sure yourself whether there is/was a problem.

I believe that you are confusing the "mute problem" with the "mixdown timing problem", (understandable, I have a lot of problems. ) I'm not sure that the mixdown timing problem is really a problem. The mute problem was real. I'm sure.

IF there is a problem, mute problem or anything else, please narrow it down on your side (i do assume you have the intelligence for that) so that the problem can be clearly repeated using a step-by-setp procedure, and share it so it can be researched. Thanks in advance.

As I'm sure you realize, some problems lend themselves to being narrowed down so that it can be clearly repeated using step-by-step procedures and some problems are intermittent and not so easy to narrow down and reproduce. The best I got with tracking the mute problem down is that it happened when I was using Asynth instead of Minimogue. Exactly when the problem showed up was not repeatable- such is life. But, whenever I had the problem (go back and read the appropriate thread if you want the details) it would go away if I replaced Asynth with Minimogue. The curious part was that the sequence and rack that had the mute problem had nothing to do with the sequence and rack that Asynth was in.

Asyth used more CPU than Minimogue and my hunch is that the problem has something to do with what happens when things get overloaded. I have no clue why replacing Asynth with Minimogue would recover things though.

I'm going to let your "intelligence" comment slide because I'm a nice guy and I assume you're a bit stressed with the 3.0 release and all.

FYI: I'm not going to document everything MU.LAB does not. I even don't document everything MU.LAB does. The docs are a basic reference guide which should be enough so you can find everything. My own guidline is: the docs should describe everything the user cannot find on his/her own.

I'm not asking you to document everything MU.LAB doesn't do. Just the things that a reasonable user might expect to work that don't. Like the fact that you MU.LAB modules don't respond to midi command from any source other than midiin. Just for example. Just making clear that you can only record from midi in and how midiin is treated "special" from other midi activity that can go on inside MUXs and racks would help

I didn't start by reading the documentation but I did read it after I started running into problems. It didn't cover the areas that cause me problems.

Sooo my suggestion is this. When you put in a new feature, like a module, think about the capabilities that module can have as a stand alone thing. DO NOT JUST THINK ABOUT WHAT CAPABALITIES OF THAT MODULE YOU MAY USE AND HOW YOU WOULD USE IT. Then if practicale considerations such as MUTOOLS resources don't allow you to fully implement the capabilities of that modules then DOCUMENT the limitations. Is that really too much to ask for? (I know you don't want to talk about these old issues any more but they are the examples fresh on my mind.) Just think about what I'm saying a bit.

I can imagine that MU.LAB is fairly, but hardly "rock", solid if used in a certain way but once it's out of it's comfort zone it often fails.

Please elaborate

We've pretty much covered this a lot but I'll say it one more time. When I use MU.LAB in a way that the designers didn't seem to take into consideration and certainly didn't design for but which is perfectly reasonable given the documentation and more importantly the options that MU.LAB allows to be set up then it often fails. In your own words.

but i did not take into account that midi vsts can output cc and that it can be handy to use them towards mu plugs too.

That kind of thing. Being able to hanle all reasonable cases, especially when the documentation doesn't warn otherwise is part of a product being "rock solid".

MU.LAB also crashes from time to time. I've had two blue screens today not counting the other MU.LAB crashes. I can't remember the last time I had a windows blue screen. That's not good.

Besides that there are just wierd things that happen from time to time. I can't reproduce them, that doesn't mean that they are not real and happening. To be sure, many times wierd things happen because of my operator error. But some things are not operator error, like the wierd mute on some of the drum beats when a differnt module is plugged in. That's just not "rock solid" software.

In spite of that, I like some of the MU.LAB concepts. I like the basic structure. I don't even need more features, just a robust implementation of the current features. Of course, we don't really agree on what's a feature and what's a bug

Peace,

John

[johnjaypl]

John, I think you're approaching MU.LAB from a different direction from many of its existing users and this means you're hitting use cases that (a) haven't been hit before and (b) haven't been thought of. (I'm not saying all MU.LAB users work the same way -- far from it. But I'm sure we've all learnt to avoid working certain ways when we've seem "strange things" happen and said nothing!)

The corollary is that you're uncovering unexpected behaviour. Which is a good thing! Even better, you're reporting it.

The other corollary is that the unexpected behaviour is undocumented - it's not been planned to work in that unexpected way, so expecting the documentation to explain it is unreasonable.

Unfortunately, you've joined the development cycle just before a major release. Some of the behaviour you're identifying presumably needs changes that would jeopardise that release by introducing a scale of change that would likely make the application less stable and more error prone. I'm sure had you been having these issues back when the development of MU.LAB 3.x started, many would be cleared.

Don't get put off by the fact the issues aren't being cleared right now. It's not because they're not important.

(Do I get the job in PR?)

I pretty much agree with what you say except for:

The other corollary is that the unexpected behaviour is undocumented - it's not been planned to work in that unexpected way, so expecting the documentation to explain it is unreasonable.

Mostly because it doesn't tell the whole story of what I was talkng about.

My experience is:

Step 1) I try something that seems like it should work and it doesn't. I figure out exactly what isn't working.

Step 2) I report the "bug"

Step 3) Often (not always) I'm told words to the effect, "that's not a bug, we don't expect that to work."

What I find unreasonable is to allow a module with midi controls to be imbedded in a flow. Allow the controls of that module to be mapped but then not work. Then, when someone reports the behavior say, it's not really a bug, of course we didn't document that behavior, it's on our wish list. But that's just my opionon of what is and what is not reasonable.

On another note, I found a different way to do what I was trying to do by recording midi produced my MU.LAB so I may not get back to that thread. I did appreciate your help though.

John

[MuTools]

The last thing you wrote about the mute problem is that you were not sure yourself whether there is/was a problem.

I believe that you are confusing the "mute problem" with the "mixdown timing problem", (understandable, I have a lot of problems. ) I'm not sure that the mixdown timing problem is really a problem. The mute problem was real. I'm sure.

Your latest messages:

http://www.kvraudio.com/forum/viewtopic ... 07#4006807
http://www.kvraudio.com/forum/viewtopic ... 62#4007762

The best I got with tracking the mute problem down is that it happened when I was using Asynth instead of Minimogue. Exactly when the problem showed up was not repeatable- such is life. But, whenever I had the problem (go back and read the appropriate thread if you want the details) it would go away if I replaced Asynth with Minimogue. The curious part was that the sequence and rack that had the mute problem had nothing to do with the sequence and rack that Asynth was in.

Asyth used more CPU than Minimogue and my hunch is that the problem has something to do with what happens when things get overloaded. I have no clue why replacing Asynth with Minimogue would recover things though.

Me neither.

If it's only happening with 1 or 2% of the VSTs, i assume it's a VST plugin problem. And, FYI, i cannot resolve bugs in VST plugins. And there are many! buggy VST plugins and i must be careful not to loose precious R&D time on researching buggy plugins. That's why i'm sometimes a bit sceptic regarding VST plugins issues. If a certain issue occurs with many different VST plugins then the case is growing.

If you can repeat it (sometimes) using MU.LAB plugins only, or if you have a issue with MU.LAB's VST engine that can be clearly described, then we get closer to a researchable issue.

I'm going to let your "intelligence" comment slide because I'm a nice guy and I assume you're a bit stressed with the 3.0 release and all.

Strange that you take the comment negative.
I almost wanted to ask why.

I'm not asking you to document everything MU.LAB doesn't do. Just the things that a reasonable user might expect to work that don't. Like the fact that you MU.LAB modules don't respond to midi command from any source other than midiin.

They do. It's only about the cc mapping of mulab's own plugins which is only effective for MIDI input because their parameters can be automated directly.
I'll evaluate documenting this.

I can imagine that MU.LAB is fairly, but hardly "rock", solid if used in a certain way but once it's out of it's comfort zone it often fails.

Please elaborate

We've pretty much covered this a lot but I'll say it one more time. When I use MU.LAB in a way that the designers didn't seem to take into consideration and certainly didn't design for but which is perfectly reasonable given the documentation and more importantly the options that MU.LAB allows to be set up then it often fails. In your own words.[/quote]

I'm not interested in vague or general statements like "often fails".

I'm only interested in concrete reports, preferrably as detailed as possible, so it can be researched, and fixed.

That's what i still mean with: Please elaborate. If you have other MU.LAB issues besides the ones you already reported, please list them with relevant details. Thanks.

but i did not take into account that midi vsts can output cc and that it can be handy to use them towards mu plugs too.

That kind of thing. Being able to hanle all reasonable cases

Are you perfect? Do you see all cases all the time?
If so, respect for that.
Talking about myself: I'm doing my best, no more, no less.

About the MIDI cc issue: I regard this case closed, i won't invest more words on that. It will be improved in a future version. Same applies to the "bi-directional" issue.

especially when the documentation doesn't warn otherwise is part of a product being "rock solid".

Ok, we have different definitions of the term "rock solid".

For me, rock solid especially means: Stable and Usable!

MU.LAB also crashes from time to time. I've had two blue screens today not counting the other MU.LAB crashes. I can't remember the last time I had a windows blue screen. That's not good.

Understand that i can't do much with such reports.

I need technical descriptions as detailed and narrowed down as possible.

Besides that there are just wierd things that happen from time to time. I can't reproduce them, that doesn't mean that they are not real and happening.

Maybe. But it also means i can't research them until the report is explicit enough. I won't start hunting ghosts.

To be sure, many times wierd things happen because of my operator error. But some things are not operator error, like the wierd mute on some of the drum beats when a differnt module is plugged in. That's just not "rock solid" software.

About the mute problem: see your own mail linked above. If you have a specific report about a mute problem, let me know.

(i'm repeating myself again)

Of course, we don't really agree on what's a feature and what's a bug

For me, a bug is something which is intended to work and doesn't.