Waveform new features requests

[dRowAudio]

We need the feature to be able to automate vsts placed inside a rack. Otherwise I can't process right or left channel separately where I want to use automation.

You can already do this. Simply set up your rack as desired and then make sure the rack editor window is open. Then drag the "A" or "+" automation track creation icons on to the plugin you wish to automate.

You can also select them when clicking on these icons from the "Master Parameters" list but I agree this is a bit misleading and they should be in their own "Plugins in Racks Parameters" list which would be easier to find. I'll add this to the backlog.

[whyterabbyt]

they should be in their own "Plugins in Racks Parameters" list which would be easier to find. I'll add this to the backlog.

Listing them separated rack by rack would be more helpful still. (Can racks be named, Ive never thought to see? Named rack by rack would be better still.)

[mochiaki]

I want melodyne editor synchronized with other tracks when scrolling, dockable or integrated with clip layer effect.

[solomute]

We need a 32 to 64 bit bridge for 32-bit vsts.

[solomute]

@dRowAudio
I have talked to a guy who works in a real hw studio and he told that in real hw studio you can easily process L or R channel of stereo applying different effects individually. I suppose that the same feature could be implemented in waveform. The proposed above method of creating additional 2-3 tracks is kind of clumsy and non-rational since it requires using two copies of the same vst. I have come across a vst plugin called oversampler.dll. That vst oversamples any vst 2x for which you rename oversampler.dll to nameofplugintobeoversampled_os.dll and then you use that nameofplugintobeoversampled_os.dll instead of original dll. both dlls should be in the same folder. The creator of that plugin told he somehow hacks internally the vsts to be oversampled. So may be waveform can implement his achievements to turn stereo tracks to dual mono tracks and use one hacked copy of a vst plugin to process channels separately. Perhaps the second copy can be just a copy of the vst duplicated in RAM if that hacking is impossible but a user is releived from the necessity to create additional 2-3 tracks and making clones of vsts.

[dRowAudio]

We need a 32 to 64 bit bridge for 32-bit vsts.

This isn't currently on our roadmap and is unlikely to make it on there as it is a very involved task and won't be useful for enough of our users.

32-bit plugins are gradually being phased out (or rather almost all plugins built these days are also built as 64-bit) this leaves only a handful of rather antiquated plugins only available as 32-bit. There are 3rd party tools (such as JBridge) which are dedicated to this task so for the small number of 32-bit only plugins I would recommend using these.

[dRowAudio]

@dRowAudio
I have talked to a guy who works in a real hw studio and he told that in real hw studio you can easily process L or R channel of stereo applying different effects individually. I suppose that the same feature could be implemented in waveform. The proposed above method of creating additional 2-3 tracks is kind of clumsy and non-rational since it requires using two copies of the same vst. I have come across a vst plugin called oversampler.dll. That vst oversamples any vst 2x for which you rename oversampler.dll to nameofplugintobeoversampled_os.dll and then you use that nameofplugintobeoversampled_os.dll instead of original dll. both dlls should be in the same folder. The creator of that plugin told he somehow hacks internally the vsts to be oversampled. So may be waveform can implement his achievements to turn stereo tracks to dual mono tracks and use one hacked copy of a vst plugin to process channels separately. Perhaps the second copy can be just a copy of the vst duplicated in RAM if that hacking is impossible but a user is releived from the necessity to create additional 2-3 tracks and making clones of vsts.

I don't really understand the problem here? What do you mean by "dual-mono tracks". In Waveform, a track simply has a L & R channel. You can easily use a Rack to route the output of a track to any channel of a single plug instance.

How you do this depends on your source files, if they're mono, you'll need two tracks sending to the same Rack instance, if they're stereo, you can do it on a single track by disabling the L/R channels of two separate clips.

If you have a stereo file, you can always process the L/R channels of a plugin differently by routing them through a rack.

I imagine the trick the oversampler.dll plugin is using is similar to Automap and JBridge. It's probably simply loading the original plugin dll and wrapping it in some oversampling/downsampling algorithms. I don't understand what advantage this would give us though? We already host plugins and give you near infinite routing possibilities with Racks.

[chico.co.uk]

<snip>

[solomute]

I don't understand what advantage this would give us though? We already host plugins and give you near infinite routing possibilities with Racks.

Ok, racks will do. i don't like 64-bit which is definitely a marketing trick to move people to new software and i like old 32-bit plugins. They are less cpu intensive sometimes and do the job the same good way if not better.

[dRowAudio]

I don't understand what advantage this would give us though? We already host plugins and give you near infinite routing possibilities with Racks.

Ok, racks will do. i don't like 64-bit which is definitely a marketing trick to move people to new software and i like old 32-bit plugins. They are less cpu intensive sometimes and do the job the same good way if not better.

Well there shouldn't be any inherent differences between 32 & 64-bit plugins. 64-bit plugins may have slightly larger binary sizes and perhaps use slightly more RAM (we're only talking a few MBs though).
In a lot of cases using 64-bit plugins should be quicker as you don't have to resort to tricks to avoid addressing large files etc. which are out of the 32-bit address space. They shouldn't naturally use more CPU though, remember they still use 32-bit sample processing pipelines, they just have a 64-bit address space and 64-bit sized pointers.
If you have more than 4GB of RAM in your machine it's just wasted if you use a 32-bit app.

[Lutin mutin]

For people who don't like the 64bits and are in love with the 32 bits plugins, I want to remember them that the Tracktion company is one of the rare DAW companies to propose 2 identical DAWs :
- one entire DAW version in 32 bits (for 32 bits lovers and/or 32 bits plugins owners), and
- An other DAW version in 64 bits.

I don't know a lot of other companies doing this...

My 2 cents...


Note :
why don't ask to the plugins software companies to do 2 versions of their plugins (32 bits and 64 bits) as Tracktion does ?

[whyterabbyt]

For people who don't like the 64bits and are in love with the 32 bits plugins, I want to remember them that the Tracktion company is one of the rare DAW companies to propose 2 identical DAWs :
- one entire DAW version in 32 bits (for 32 bits lovers and/or 32 bits plugins owners), and
- An other DAW version in 64 bits.

I don't know a lot of other companies doing this...

Actually most companies have done this as the market transitioned from mainly 32-bit to mainly 64-bit. The 'big names' dont really any more, except for Ableton Live but most of the 'indies' still do eg Bidule, Usine, Mulab etc

why don't ask to the plugins software companies to do 2 versions of their plugins (32 bits and 64 bits) as Tracktion does ?

Most active software companies do; there are only about 3 plugins which are 64-bit only, and the vast majority of the plugins which are not 64-bit as well as 32-bit are either no longer being supported or developed, or were built in something like Synthedit or Synthmaker.

[whyterabbyt]

i don't like 64-bit which is definitely a marketing trick to move people to new software.

utter tosh. the single point of momentum is the memory limits inflicted by a 32-bit OS. And there is almost no new 64-bit only software to speak of; there's only about 3 plugins which are 64-bit only, and I dont think there's a single hosts which has never existed as a 32-bit version.

[solomute]

If am not mistaken those memory limitation for 32-bit OSes exists only for microsoft windows and for example 32-bit linux supports more than 4gb RAM. If it is so than that limitation was just a commercial trick and a shift to 64-bit had been planned a long time before. Anyway I have nothing against 64-bit. The problem is that by refusing to create internal support of 32-bit by bridges or other way the companies hiddenly let us use jbridge. And that jbridge has become a kind of monopoly and it means that if jbridge can't process this or that specific vst you have no other choice than to abandon and forget that vst forever. But why should i forget it? Maybe it's the best vst in the whole history of vsts.

[dRowAudio]

As far I can I can tell from this, Windows has had PAE since Windows XP and so is able to utilise more than 4GB RAM on a 32-bit OS: https://msdn.microsoft.com/en-us/librar ... s.85).aspx

However, as far as I can tell (someone correct me if I'm wrong though), this still limits individual apps to a 32-bit address space. For most apps this would be fine but for a plugin hosting app like a DAW, all plugins are loaded into the same address space and hence limited to 32-bit addresses and 4GB RAM. This isn't usually a problem but can be for sample heavy plugins. There are ways around the 32-bit address limitation but are complex so often not used by plugins and can incur additional overhead. All in all, native 64-bit is easier and more efficient to work in.

It's not that we're refusing to add a 32-bit bridge out of principle, or as some kind of commercial trick, it's just an extremely complex task, would propagate through the whole code base and is not the most efficient way to use plugins anyway. If it took us 6 months to do this, that time could be spent better elsewhere. All of our customers happily on the 64-bit version would complain that we've abandoned them and developing features they could also use.

Jbridge is a commercial tool specifically designed to solve this problem and is relatively low cost. As their entire focus is on supporting this feature it's probably a good idea to report plugin compatibility problems to them. I imagine as more and more plugins move towards 64-bit, they'll have a bigger and bigger investment in those 32-bit only plugins.