MuTools

MuTools · Post by **MuTools** » Thu May 19, 2016 4:31 pm

Good suggestion, thx!

magicmusic · Post by **magicmusic** » Thu May 19, 2016 4:33 pm

@Taifunk thanks, the way with the meta parameter sound good. i try out.

mutools wrote:PS: Which exact Reaper version and which Windows version?

And when the crash occurs do you get a Mu style red popup alert? Or a Windows style crash alert?
In the latter case, please email me the crash details that should be available in Windows event viewer.

is windows crash alert. I test now with other song. MUX work ok here. seem a 64 bit many memory usage problem again, as i have in past and you fix. but the song that show problem in the past, work ok too. only the new song i do for test of MUX 7 have this problem. because i test MUX 6 with this song later, i see happen too. but good news, i can reproduce always. with the sliders it as general slider problem. happen in browser when i move slider too. or in edit preferences when i move slider. maybe you have a idea what can cause problem.crash happen as soon click on slider. what should i send better a report.wer file from MUX 6 latest version or older MUX 7, or should i better wait for new. crash offset for MUX 6 latest is 10548d. exception code is c0 00 00 05

Taifunk · Post by **Taifunk** » Thu May 19, 2016 6:06 pm

magicmusic wrote:@Taifunk thanks, the way with the meta parameter sound good. i try out.

hoping it helps

MuTools · Post by **MuTools** » Fri May 20, 2016 8:29 am

magicmusic wrote:is windows crash alert. I test now with other song. MUX work ok here. seem a 64 bit many memory usage problem again, as i have in past and you fix. but the song that show problem in the past, work ok too. only the new song i do for test of MUX 7 have this problem. because i test MUX 6 with this song later, i see happen too. but good news, i can reproduce always. with the sliders it as general slider problem. happen in browser when i move slider too. or in edit preferences when i move slider. maybe you have a idea what can cause problem.crash happen as soon click on slider.

I did another test using MUX Vst 7.0.36 in Reaper 5.04 both 64 bit on a system with 6 GB ram. I forced ram usage of 4500 GB for MUX alone (so total mem usage is even higher, getting close to system limit) and tried scrolling the scrolbars you mentioned and all working stable, no crash.

what should i send better a report.wer file from MUX 6 latest version or older MUX 7

Euh, i'm confused, MUX 7 comes after MUX 6 so how do you mean this? Or is it a typo?

or should i better wait for new. crash offset for MUX 6 latest is 10548d. exception code is c0 00 00 05

Please make a screen video repeating the crash using the latest MUX 7.0.36 and make sure to also include the crash details in that video especially exception module name and exception offset. Thanks.

sl23 · Post by **sl23** » Sat May 21, 2016 9:05 am

pljones wrote:
mutools wrote:There is a new MuLab 7.0.39.
...
The new M7.0.39 app patch is available here: http://www.mutools.com/mulab/app-patch/index.html
Can I suggest the patch page "Condition" section provides a very clear link back to the full install page at that point (yes, I know how easy it is to get there but ... ).

I think you should change the font on your site too. Check the font here and it's much easier to read. I suspect the font you use is the old MuLab one? Due to the complaints about it, I think it's something you should consider.

pljones · Post by **pljones** » Sat May 21, 2016 10:52 am

Personally, I recommend websites not specifying font faces and especially not specifying font sizes in pixels -- use percentage or ems if you need to show some kind of variance but below 100% should be for things you don't mind not being read. If I've selected a 14pt font and the site has 12px text, it's going to mean I'm less inclined to read it as it's smaller than I'm comfortable with. (KVR uses ems.)

sl23 · Post by **sl23** » Sat May 21, 2016 11:17 am

KVR font is good. MuTools site is difficult to read, as MuLab was.

MuTools · Post by **MuTools** » Sun May 22, 2016 10:55 am

There is a new MuLab 7.0.40.

Latest changes:

Fixed a potential crash bug in the automation/modulation system when doing extreme automations/modulations ie. using high frequency loops and/or complex shapes. For such cases use audio-rate modulation.
Fixed a potential crash bug in the TF Lowpass filter, especially when modulating the cutoff while overloading the modulation system.
When a MUX patch exceeds the standard modulation system limits, now a warning is shown in the CPU meter display. This only happens in extreme situation and then solution is to use audiorate modulation.
Upon loading projects/presets that use samples, any markers that are outside the sample start-end range (eg sample has been edited elsewhere) are pulled inside that range.

The new M7.0.40 app patch is available here: http://www.mutools.com/mulab/app-patch/index.html

pljones · Post by **pljones** » Sun May 22, 2016 11:27 am

mutools wrote:

Upon loading projects/presets that use samples, any markers that are outside the sample start-end range (eg sample has been edited elsewhere) are pulled inside that range.

Does the user get notified of this?

MuTools · Post by **MuTools** » Sun May 22, 2016 11:28 am

No, markers are supposed to always be in range.

pljones · Post by **pljones** » Sun May 22, 2016 11:44 am

mutools wrote:No, markers are supposed to always be in range.

When edited by the user in the application they would have been, wouldn't they? So if the application finds they're not on load, then it's not something the user would have been prevented doing inside the application and they may not realise the markers the application is holding are outside the edited sample. In fact, they may wonder why their project sounds different on reloading and struggle to find the cause as there's no indication of what's happened. Yes, they'll be aware they edited the sample but they may believe (strongly) that this couldn't have affected things (as they probably didn't intend it to). The hint from the application would break that "spell".

MuTools · Post by **MuTools** » Sun May 22, 2016 6:15 pm

Taken note on the wishlist about notifying the user about this.

MuTools · Post by **MuTools** » Sun May 22, 2016 11:15 pm

MuLab 7.0.41 is available.

It fixes another potential crash bug in the automation/modulation system when doing extreme automations/modulations ie. using high frequency loops and/or complex shapes. For such cases use audio-rate modulation.

If you already have installed the MuLab 7.0.32 package or up, then you can apply this quick app patch:
http://www.mutools.com/mulab/app-patch/index.html

sl23 · Post by **sl23** » Mon May 23, 2016 7:32 pm

Thanks for the update and license key

MuTools · Post by **MuTools** » Thu May 26, 2016 4:07 pm

There is a new MuLab 7.0.43.

Latest changes:

Playing very short notes via MIDI while using a larger audio engine buffer size could result in hanging notes. Fixed.
Fixed a problem when using the Step Sequencer within the PolySynth.
Improved support for loading existing projects with empty audio streams.
Fixed a crash bug when switching the Multi-Point Envelope to an empty preset envelope or deleting all points.
Some other micro improvements.

A quick app patch is available here: http://www.mutools.com/mulab/app-patch/index.html

MuTools

KVR Audio

MuLab 7.0.47