MuLab 5.0.31 Test

Official support for: mutools.com
Post Reply New Topic
RELATED
PRODUCTS

Post

EvilDragon wrote:By the way - it would be great if the browser being docked is a global preference (for all projects).
Please elaborate on this. How do you see this?

I mean: When you want new sessions to start with a docked or windowed browser, then you can setup a new session like this and save it as the "New" session template. (cfr the factory New.MuSession uses a docked browser)

That said, imagine you have multiple session windows and you dock/window the browser in one of them, i don't think it would be expected behaviour if suddenly all other session windows would also change their browser to that same setting.

Bottomline is that the browser setup is something on session level not on global level, i think.

What do you think?

Post

I'm just going by my current experience with Reaper - I can dock the windows however I like and use that screenset layout as a template for all my projects. So I can have Reaper's Media Explorer docked at all times on bottom right, while above it I have my FX browser. And it's always going to be there.


Regarding multiple sessions, of course each could have their own handling - if you close the browser in one, others shouldn't be changed. (However this is not the current behavior in Reaper - if you change docking state, or change the tab from multiple ones docked, it changes for all opened projects.)


I'm just talking about this as a global starting point layout for all projects. I did notice MuLAB doesn't have many dockable windows like Reaper does, so this is a difference there. However, making a certain layout and sticking with it makes it possible to have things like this (well, at least when Reaper is concerned), and always looking like that when you open your DAW fresh:

Image

Post

Note that you can save whatever session setup to be the "New" session template. That's including the browser setup. So you can have a same static setup whenever you start a new session.

That said, i had a look at reaper's docking features and that's interesting stuff. I've taken note about this wrt future versions. By the way: Which reaper skin is that?

@Digit, this is the same topic you mentioned several times. This is an interesting new part of that puzzle.

Post

Hi Jo, did you have a chance to check out those presets yet?

Post

mutools wrote:Note that you can save whatever session setup to be the "New" session template. That's including the browser setup. So you can have a same static setup whenever you start a new session.

That said, i had a look at reaper's docking features and that's interesting stuff. I've taken note about this wrt future versions. By the way: Which reaper skin is that?
Oh, like a project template. Noted!


This is the old version of RADO skin by Nick Moritz, with a few of my own changes.

Post

mutools wrote:@Digit, this is the same topic you mentioned several times. This is an interesting new part of that puzzle.
i wondered why my ears were ringing! 8)

Post

robenestobenz wrote:
mutools wrote:M5 has a "Smart Bypass" feature on VST plugins which means that if the VST plugin is not receiving any input nor generating any output the VST plugin is bypassed so it doesn't consume CPU. In that case the green power led will change to a darker green, indicating that the plug is still active but auto bypassed. This Smart Bypass feature can be controlled via the VST plugin's context menu -> Setup Smart Bypass. By default it's Off. Does this clarifies things?
Sorry, that's not it. The power indicator is grey even while the VSTi is playing a note (or the VST is processing sound). When I first load a VST the power indicator is already grey actually. I haven't touched the Smart Bypass settings.
I can't find what you mean. Anyone else experiencing something wrong with the green process on/off button for VST plugins?

Post

Trancit wrote:Bug:

Drag some MuClips from the user library...

Start to delete sequences from the browsers sequence tab...
Sooner or later (for me mostly after 2 deleted clips) Mulab crashes...

Wasn't able to reproduce this with clips from the factory library though
I can't repeat this.

When you say "Start to delete sequences from the browsers sequence tab" you mean deleting sequences from the session so that the parts playing these sequences get a "No Sequence" title, right?

Post

mutools wrote:
pljones wrote:Possible bug... 5.0.27 64bit Windows (exe+ID update from .26).

I opened the "Pure" demo and, as previously reported, is triggers the Free constraint soft noise. I then started a new session (in "This" session - i.e. "Pure" shouldn't have been around any more) and started using the Browser auto-preview on the included 8 MuClips. The soft noise still got triggered, even though there was nothing at all actually in the session and all I was doing was using the preview! I'm not sure, but it seem to need changing from one clip to another to trigger it (although that may be more to do with my just switching back and forth before the noise triggers...).
It's not a bug. The activation / deactivation of the demo noise happens at a slow pace so when you have crossed the bounds of MuLab Free / XT but then return inside the bounds of MuLab Free / XT then it can take a couple of minutes before the noise disappears again. That's for reasons for making it more difficult to hack.
How is having an empty project with the browser open crossing the Free bounds?

Post

It's not. But if you have crossed the bounds recently and then start a new session, then it can still take a couple of minutes before the demo noise disappears. Or do you mean that the demo noise comes even more than say 5 minutes after returning inside the limits?

Post

MuLab 5.0.28 is available as an app/exe update in http://www.mutools.com/mulab/everest

What's changed:
  • Rearrange Meta-Parameters dialog was too high for most screens. Fixed.
  • When you insert a module (Rack, MixerStrip, ...) in the session MUX and name it "Preview Monitor" then all previewing will be routed to that module, so this way you canb control the preview volume and/or add effects to it and/or define to which output it should go.
  • When minimizing or resizing the main session window, the rackdesk scrollbar was not showing up properly. Fixed.
  • Fixed a bug in the preset file system causing "Couldn't load preset" alerts.
  • When a session was deactivated (Process Off) it was still consuming cpu. Fixed.
  • Browser: MIDI Files and All Files now show all drives by default so you can immediately start browsing.
  • Fixed a problem with deleting VST plugins from the browser.
  • Finetuned graphics.

Post

mutools wrote:It's not. But if you have crossed the bounds recently and then start a new session, then it can still take a couple of minutes before the demo noise disappears. Or do you mean that the demo noise comes even more than say 5 minutes after returning inside the limits?
I'll have to try being a bit more patient but yes I'm fairly sure I'd been playing with the browser for over 5 minutes after doing New Session and it was still happening. I even checked again whilst posting the message to be sure.

Post

Thanks for fixing that Jo, but it still hasn't solved the problem I had.

Here's what happens now:
I load my Session with my Presets.
I remove all association with MP's for a particular parameter and replace it with a knob straight from the source.
I save the preset.
Then restart MuLab and the preset appears as it did before I edited it.
Now I can use the arrows to select presets, I can go to the next/previous and back again to the first. But when I return to it it's changed?!

What's happening? This seems to me that MuLab is saving the preset as part of the session? But I thought it's a seperate entity completely? I understand a session saving a particular preset, obviously, but not the actual details of that preset, it's make up, etc.

Just checked if saving the session would 'update' the info regarding these presets and it does. It seems that if a session contains a preset it contains the actual details of that preset. So if you edit that preset and save it, the session still thinks you're using the old version unless you save the session as well.

Is that intentional? I don't think it should be if it is. A session should simply contain the path to the preset. Unless there's more to it than that? I have a Novation Nova and there's two ways to use it. You can use it in Patch mode where it simply plays a single sound or use it in Program mode where it's multitimbral. When you save a Patch it saves your edits, but in Program mode it saves Patch data independantly from the patches. So if I saved that Patch as part of a Program it could have different sound completely from the very same Patch in Patch mode. Hopefully that makes sense :? Perhaps this is why MuLab is doing this with presets? Though why with Mp's I don't understand? It should just be directly the parameter's themselves not front panel.
Last edited by sl23 on Sat Dec 29, 2012 1:35 pm, edited 3 times in total.

Post

mutools wrote:
Trancit wrote:Bug:

Drag some MuClips from the user library...

Start to delete sequences from the browsers sequence tab...
Sooner or later (for me mostly after 2 deleted clips) Mulab crashes...

Wasn't able to reproduce this with clips from the factory library though
I can't repeat this.

When you say "Start to delete sequences from the browsers sequence tab" you mean deleting sequences from the session so that the parts playing these sequences get a "No Sequence" title, right?
Correct...

But I could narrow it down:
It's related to the "Autopreview" function... if turned off or the autopreview is already finished, nothing happens...that's the reason, why it didn't happen with the factory clips... they are too short and playback is already done...

So to test you need clips, which are long enough (I tested with 4 bars clips) that they still play if you rightclick and choose delete...

Post

pljones wrote:
mutools wrote:It's not. But if you have crossed the bounds recently and then start a new session, then it can still take a couple of minutes before the demo noise disappears. Or do you mean that the demo noise comes even more than say 5 minutes after returning inside the limits?
I'll have to try being a bit more patient but yes I'm fairly sure I'd been playing with the browser for over 5 minutes after doing New Session and it was still happening. I even checked again whilst posting the message to be sure.
Can't repeat it. I'm playing with the browser factory muclips for about 10 min now, no noise. Hope you can find a repeatable way.

Post Reply

Return to “MuTools”