MuTools

BlackWinny · Post by **BlackWinny** » Sun Apr 16, 2017 3:34 pm

mutools wrote:If no errors occurred the log file is automatically deleted upon quit, so no unnecessary cumulation.

Ah, thank you Jo!

imstre · Post by **imstre** » Sun Apr 16, 2017 7:15 pm

problem with sound

stops and sounds continuously; Maybe I bad

MuTools · Post by **MuTools** » Sun Apr 16, 2017 10:13 pm

I don't know what you're doing but you're clearly overloading the whole system and that's why it sounds bad. At least there is some Parameter Event Generator that is heavily overloaded.

BlackWinny · Post by **BlackWinny** » Sun Apr 16, 2017 10:50 pm

mutools wrote:I don't know what you're doing but you're clearly overloading the whole system and that's why it sounds bad. At least there is some Parameter Event Generator that is heavily overloaded.

There could be for example some Windows background tasks which overload temporarily the memory (and perhaps also the CPU).

I would highly suggest our friend to temporarily stop (a true "Quit" of them, not only a single "Disable") ALL the unnecessary background tasks (not only those visible in the Windows task bar near the clock but also many invisible ''non system' tasks shown in the Windows Process Explorer) and to make these new tests with of course the computer disconnected from internet (given that the antivirus is totally unloaded from the memory) then to fully restart the machine immediately after the tests to reload the background tasks in their usual state.

That way, it is certain that many disturbing invisible events in the CPU and the memory would be avoided for the tests.

MuTools · Post by **MuTools** » Sun Apr 16, 2017 11:00 pm

I'm sorry my message caused confusion. With "overloading the whole system" I meant MuLab's system, not the OS. Although there may be overlaps in the overload eg CPU usage.

BlackWinny · Post by **BlackWinny** » Sun Apr 16, 2017 11:03 pm

mutools wrote:I'm sorry my message caused confusion. With "overloading the whole system" I meant MuLab's system, not the OS. Although there may be overlaps in the overload eg CPU usage.

... but I keep my suggestion, anyway. It could be interesting to hunt some puzzles in the physical memory management causing some unattended "interferences" with the internal management in the DAW.

imstre · Post by **imstre** » Mon Apr 17, 2017 8:04 am

my windous is fully automated for muzik - is no anti-virus,everything OFF What is the unnecessary!

maybe the computer itself is not capable of
8 ram, cpu 1.7 core i5

MuTools · Post by **MuTools** » Mon Apr 17, 2017 8:16 am

Your'e generating many thousands of parameter events per second, that's an overflow situation, it also doesn't make any musical sense.

That's most probably also the reason for (some of) the crashes you were encountering. For there was one place in the code where i didn't add explicit crash protection in case some specific aspect would overload cause it was unreal that this would ever happen, but based on what i saw in the crash reports i think you did trigger that case so that's why in M7.3.17 i added explicit protection even in that case, eventhough now it takes a tiny little bit more CPU cause the test has to be made.

If you would really not understand why it's overflowing (pls double and triple check the routings in your project), then pls remove all VSTs from that project that causes the "Error PEG[199]" and save it as a temp version and zip + post it. But make sure the project does not contain VSTs and make sure the project does cause the "Error PEG[199]" in the log file. You can have a live view at the log file via MULAB menu -> Help -> Command Line -> "show log"

imstre · Post by **imstre** » Mon Apr 17, 2017 9:33 am

If you would really not understand why it's overflowing (pls double and triple check the routings in your project), then pls remove all VSTs from that project that causes the "Error PEG[199]" and save it as a temp version and zip + post it. But make sure the project does not contain VSTs and make sure the project does cause the "Error PEG[199]" in the log file. You can have a live view at the log file via MULAB menu -> Help -> Command Line -> "show log"[/quote]

Thank you, I understood

I think that this "testing something" many uses cpu. Sorry

question: Mulab version 4.5.2. 64bit link is ?

MuTools · Post by **MuTools** » Mon Apr 17, 2017 9:47 am

I don't get any errors with that MUX preset. (inserted it in a clean new project)

imstre · Post by **imstre** » Mon Apr 17, 2017 10:05 am

mutools wrote:I don't get any errors with that MUX preset. (inserted it in a clean new project)

Thanks! I am doing so

not see the main page prices for upgrade version 4.5.2; interesting to know

MuTools · Post by **MuTools** » Mon Apr 17, 2017 10:16 am

From M4 to M7 = new M7 = 69 euro = Very low price!

imstre · Post by **imstre** » Mon Apr 17, 2017 10:31 am

mutools wrote:From M4 to M7 = new M7 = 69 euro = Very low price!

you are completely right!

watching version 4, 5, 6; interesting as the child grows

I really liked the 4-5 version rack appearance because see how much used
may be elongated, narrow squares

sorry, Do not turn head.

sl23 · Post by **sl23** » Tue Apr 18, 2017 8:32 pm

Sorry for being a pita about this, but can you revert to the original way of working for the front panel pics.
If that's not the direction you want, then please consider keeping the current way and adding the old way as an option. Giving users the best of both.

The trouble with how it is at the moment is that you can't expand the window as it affects the picture. Which gives a distorted view of your front panel 'project.' In order to keep aspect ratio and proper size when temporarily enlarging, you have to edit the picture, mess about with your front panel, then re-edit the picture!!!

This is a real annoyance, please can you do something about this?

MuTools · Post by **MuTools** » Tue Apr 18, 2017 9:49 pm

sl23 wrote:The trouble with how it is at the moment is that you can't expand the window as it affects the picture. Which gives a distorted view of your front panel 'project.' In order to keep aspect ratio and proper size when temporarily enlarging, you have to edit the picture, mess about with your front panel, then re-edit the picture

Solution: As long as you're designing your front panel, use a large enough picture (evenetually with extra empty space) so you have all extra workspace you need during design. Then when it's ready you can optimize the size of the front panel and its background picture.

MuTools

KVR Audio

MuLab & MUX VST 7.4.6