@devs: As much as I like to not have these silly VST, VST3 etc. in front I am not sure if at least a differentiation between FX and instruments would be helpful... i.e. first all FX alphabetically then the instruments or other way round...
Or VSTi's in italic font to directly visually differentiate them in mixed list?
This is why you have a separate Instruments section in the left side pane... TBH I honestly never spend time with "All Plugins" selected, it's either Instruments, or going into individual categories per FX type...
btw- maybe this has something to do with the problem that I never hear the attack of the first note/kick/snare if the cursor was right on it before hitting the play button(?) "tiny fade in" is not ticked
Quote:
Originally Posted by akademie
Hi Reflected,
I am pretty sure that it is not because of splitting "automation item" but splitting the actual audio item, so that every slice has now fade-in applied. Check their properties (F2) or zoom in closelly to see the tiny fade-in.
it is not because of the audio
you can see in the video that before I splitted the automation item, the attack was clear as expected, after splitting the attack is gone even if the shape stay the same.
you can see in the video that before I splitted the automation item, the attack was clear as expected, after splitting the attack is gone even if the shape stay the same.
Can you share the project?
(link you posted is not working)
for some reason, when spliting the automation items, it loses the attack which is completely unexpected behaviour.
There is a "transition time" setting in the automation item properties that defaults to 12 ms. This can be changed per-automation item and the global default can be changed in Preferences > Editing Behavior > Automation.
There is a "transition time" setting in the automation item properties that defaults to 12 ms. This can be changed per-automation item and the global default can be changed in Preferences > Editing Behavior > Automation.
Kinda really depends. There are some plugins that work better as VST3 than VST2 (Melodyne, Halion 6, Surge...) There are a number of steps forward in there, too (more than one MIDI port per plugin, better output handling...)
Either way if any new developer ever shows up it's gonna be VST3. Also note that VST3 is truly open source and cross-platform, and VST2 isn't. This makes it practically the only realistically viable option if one ever considers Linux...
Not all is so grim.
I agree with Justin that they don't need to cover every combination.
Right. So just the option you need. Got it.
Make whatever argument you want. VST3 is not as stable as VST2. So when doing a multi-type search it would be nice to filter VST3 when both types are available.
Last edited by Klangfarben; 05-21-2020 at 06:44 AM.
Kinda really depends. There are some plugins that work better as VST3 than VST2 (Melodyne, Halion 6, Surge...) There are a number of steps forward in there, too (more than one MIDI port per plugin, better output handling...)
So that's the reason why one of the leading companies like Native Instruments hasn't switched to VST3?
It might be true for a couple of plugins. But that can't be used as a general statement.
Quote:
Either way if any new developer ever shows up it's gonna be VST3. Also note that VST3 is truly open source and cross-platform, and VST2 isn't. This makes it practically the only realistically viable option if one ever considers Linux...
VST3 enables musicians to finally make the switch to Linux, said no one ever.
Quote:
Either way if any new developer ever shows up it's gonna be VST3.
Well, maybe you should also mention that the VST2 SDK was abandonned and there's literally no choice for new devs.
Again, this really really depends. Some devs did nail VST3 and it's just as stable as VST2. The plugin framework (VST3 vs VST2) itself is not what makes the plugin crash, it's what devs do with it and how they understand (or not understand) how it's supposed to work.
Again, this really really depends. Some devs did nail VST3 and it's just as stable as VST2. The plugin framework (VST3 vs VST2) itself is not what makes the plugin crash, it's what devs do with it and how they understand (or not understand) how it's supposed to work.
So this thing should be optional(enabled/disabled + VST2/VST3) and perhaps per plugin.
Per plugin? That's what the # is for. Otherwise, now we're just making the case for yanking the code entirely and letting users decide on a per-plugin basis, which we already can do.
Let's keep it simple:
1. Some users will want to see both types (default behavior)
2. Some users will prefer VST3 plugins over VST2 (new option)
3. Some users will prefer VST2 over VST3 (requested option)
I hope Justin sees some of the support for #3 and agrees it's not too much trouble to add, but otherwise, hey, 2 out of 3 ain't bad.
We don't need to turn this into a debate about which formats are better or why. Just stick to the 3 use-cases above. Frankly, Justin said he wasn't interested in adding #3, and while I disagree and hope he changes his mind, the browser is much better today than it was last week and I'll take that as a huge win.
Again, this really really depends. Some devs did nail VST3 and it's just as stable as VST2. The plugin framework (VST3 vs VST2) itself is not what makes the plugin crash, it's what devs do with it and how they understand (or not understand) how it's supposed to work.
From my simplistic point of view:
I have multiple plugins from multiple manufacturers in VST2 and VST3 format.
If a plugin crashes it is usually always a VST3. Most of the time VST2 gives no problem.
So as a rule of thumb I always use VST2 when available.
Only when some plugin misses a feature in VST2 that I need and has it in VST3 I use the latter.
Hence why I, like many others, would appreciate a VST2 priority filter.
If Justin has no interest in doing it I am fine as well. There are workarounds for it and there are bigger issues to solve.
If I don't get the filter I want I won't envy other people for getting theirs. Something for someone is always better than nothing for anyone.
Again, this really really depends. Some devs did nail VST3 and it's just as stable as VST2. The plugin framework (VST3 vs VST2) itself is not what makes the plugin crash, it's what devs do with it and how they understand (or not understand) how it's supposed to work.
Or the fact that VST3 makes the developers jump through a lot more hoops, has a lot more pitfalls and is a general PITA for them. Perhaps maybe why NI decided to not port their plugins to a spec that was introduced over a decade ago? Along with a host of other developers. There's a reason for that. Most developers will not abandon VST 2.4 until it is dead and buried.
Rather than continue the argument, let's just say there are a lot of users (many who have already commented here) and many developers that avoid VST3 when possible. So again, it would be a welcome option to have the ability to filter them. We aren't talking about every combination under the sun here so let's not act like it.
Play head is jerky both in arrangement and midi editor only if mouse cursor is inside midi editor.
Interesting, I reported a similar problem with the playhead slowing down and almost freezing, when you move the mouse near the playhead when it is running. However, it is related to a certain preference setting as detailed below- this was reported for v6.10+dev0511 - May 11 2020. Not sure if they are connected but worth mentioning:
I've noticed a graphics issue on mac when you have throttled mouse events (wheel/swipe/move) disabled (no ticks on). Using metal BTW in Mojave. Whilst scrolling and moving around projects is a lot smoother and improved with mouse events set like this, if you move your mouse near the play cursor which is moving, you get MAJOR lag on the UI and playhead. You can pretty much stop the playback temporarily. This isn't normal behaviour? Switch back to enabled throttled mouse events (ticked) this stops happening (but the smoother scrolling of a project is lost).
Throttled mouse events (wheel/swipe/move) TICKED
Throttled mouse events (wheel/swipe/move) NOT TICKED
There is a "transition time" setting in the automation item properties that defaults to 12 ms. This can be changed per-automation item and the global default can be changed in Preferences > Editing Behavior > Automation.
Interesting, I reported a similar problem with the playhead slowing down and almost freezing, when you move the mouse near the playhead when it is running. However, it is related to a certain preference setting as detailed below- this was reported for v6.10+dev0511 - May 11 2020. Not sure if they are connected but worth mentioning:
I've noticed a graphics issue on mac when you have throttled mouse events (wheel/swipe/move) disabled (no ticks on). Using metal BTW in Mojave. Whilst scrolling and moving around projects is a lot smoother and improved with mouse events set like this, if you move your mouse near the play cursor which is moving, you get MAJOR lag on the UI and playhead. You can pretty much stop the playback temporarily. This isn't normal behaviour? Switch back to enabled throttled mouse events (ticked) this stops happening (but the smoother scrolling of a project is lost).
Throttled mouse events (wheel/swipe/move) TICKED
Throttled mouse events (wheel/swipe/move) NOT TICKED
Correct, Throttled mouse events (wheel/swipe/move) TICKED solves the issue.
Could this be documented in the help file? And an example code please?
If you run action 'ReaScript: Open ReaScript documentation (html)...' in current +dev/rc it's there already in TrackFX_AddByName() description:
Quote:
If instantiate is <= -1000, it is used for the insertion position (-1000 is first item in chain, -1001 is second, etc). fxname can have prefix to specify type: VST3:,VST2:,VST:,AU:,JS:, or DX:, or FXADD: which adds selected items from the currently-open FX browser, FXADD:2 to limit to 2 FX added, or FXADD:2e to only succeed if exactly 2 FX are selected. Returns -1 on failure or the new position in chain on success.
edit:
I used +dev0521a which has this but not v6.11rc1, so I guess it'll come back in next release cycle.
If you run action 'ReaScript: Open ReaScript documentation (html)...' in current +dev/rc it's there already in TrackFX_AddByName() description:
edit:
I used +dev0521a which has this but not v6.11rc1, so I guess it'll come back in next release cycle.
Oh, I thought it was preserved in the next dev builds and I did open the reascript documentation but nothing was written there. That is why I asked how is it used and reported the lack of documentation. My bad!
Also, question about FXADD: parameter, what the purpose of it? It works, but you still need to open fx browser for specific track somehow and to select effects manually, as there's no API for that, so it all defeats FXADD: parameter purpose or i don't understand something.
I've been using it for a script which adds a loudness measuring effect at the beginning and the end of the fx chain. It is definitely useful if you need to insert an effect at a specific spot in the chain