Milton Sica

Thanks, but how and where add the midi events ?

Thank you very much. I figured it could be something like that, but I don't know how to put it like that. If you could detail me better, a step by step on how to do it would be very good. On the other hand, I saw a recent post on Feedback from 2011.11 a user reporting the same problem I have.

I have the equal problema, but in another Plugin: Accordion !

I have a VST Instrument that, under unknown circumstances, gets a stuck note. That note is playing all the time. The solution I found was to open the Turn Off and On plugin interface, but I think it would be much better if I put a controller on the midi track to do this every time it runs. Is there a way to do it?

That question is clarified where to configure. I think the biggest issue is that of better and more documented technical clarification of the entire scope of checking or unchecking such options.

I would like to suggest that this MMCSS issue be further explored in the documentation, as I realize that, like me, many other users are experiencing the same difficulty.

Hello. This was a request I made and the explanation of the calculation that follows was given to me by @msmcleod. The clarification on how the calculation is done was born from my understanding, wrong, that if I increased the BPM of the song by 10%, it would also suffice to stretch the line by -10%. My miscalculation example: Original BPM: 110 10% increase = 11 Final BPM: 121 I thought that the reduction in stretch should be 90%, but no. This is the correct calculation in the application algorithm approach. See calculation example: If you want to change it from 110 bpm to 120 bpm, then stretch it as you originally did using CTRL + SHIFT + drag, but by 91.66% - i.e. ( 100 / 120 ) * 110 The result of this operation displays more than one decimal place. The display now allows you to perform the calculation and get much closer to synchrony.

I'll try to reproduce and see if I can get the file you ask for.

Experiencing daw response as "NOT RESPONDING" on AutoSave operation which I have configured to only after 2 changes. The save, as I noted, seems to have taken place, but has crashed the application. I had to close and reopen,

@Noel Borthwick this is a great idea.

Thank you all. Yes, there are already several ways to identify 32/64-bit PLUGINS. In addition to the excellent tools and colors, I found the one that follows in Browse plugins more direct and enlightening.

Thanks. Now working !

I downloaded VST Inventory Tool but.....not work

Where can I find it for download?

You say VST2 or VST3 which appears on the right in the include menus ? Or this ? Is this 32-bit information placed by Cakewalk or is it already contained in the description of the DLL itself?

Recently I discovered that it is possible to identify if a DLL was compiled for 32 or 64 Bits, as shown below. I ask if it would be very difficult to make this information more "humanized" in the Plugin's properties screen. I believe that this implementation could help us migrate more easily to using PLUGINS that are already compiled in 64 bits.

Is this already in build 17 or will a new EA come out?

In one of the threads I commented on this the explanation is given. I'll try to find.

I agree with all your posts. The UI needs to evolve, be modernized with usability improvement. A friend and I @Herbert Zio.we have already brought suggestions for quick implementation of folder resources in the console view. Something that is much faster than creating PRESETs, etc.

Some time ago I had problems with Ozone loading slowly and I received a tip, I don't remember if it was from @msmcleod, which was to have the Ozone Plugins validation application running in the background. This fixed the slowdown for me.

I also have AUTOMATIC SAVING enabled, as it is an excellent tool that preserves changes made to the project. Protecting from power surges, etc. Do I understand that for better performance I must disable this option or was it a suggestion to test where the slowness is happening?

Thanks. I'm going to use it for a few days without administrator exclusivity and observe behaviors. Thanks.

There are already some reasons. I would like to go into more depth with regard to the issue of application performance, as I always thought that, running as an Administrator, the application would have powers over the machine that could avoid unnecessary crashes, among other things. What do you think ?

Microsoft support reports this: "The difference between running a program as Administrator or local, is precisely the level at which this program can access your machine. Generally, programs that use this resource are programs that need to change or create records on your computer . The location does not grant these permissions to the application." What do you base your opinion on? "unexpected problems:" If you could list some or even make a comparison between one mode and another. Would be great. I really want to learn about this.