foo_vst: VST 2.4 adapter

I've misunderstood you. Yes, that should be possible. The obvious problem is that such a visualization will only work with already-processed data.

But I think there is a better solution for analyzer-only VSTs. I can make my dsp service to pass data to actual analyzer VST with a delay that is equal to the output buffer size. Delay would be introduced for VST only, not for the whole processing chain. Here is the only problem is to obtain the output buffer size. Is it possible?

foo_vst: VST 2.4 adapter

I'm not entirely sure what you mean by "time-coded", but information is given about timing, and pure PCM should be available in the vis subsystem. I'm pretty confident it'll work, based on conversations I've had with Peter. However, I know nothing about the specifics of that subsystem. I'm trying to recruit one of the devs who actually knows something to provide a bit more context.

From what I seen in the SDK, it is the case. You can retrieve sample timing along with the pure PCM data. Information is giving regarding sample timing, for A/V sync.

Quote

I can make my dsp service to pass data to actual analyzer VST with a delay that is equal to the output buffer size. Delay would be introduced for VST only, not for the whole processing chain.

foo_vst: VST 2.4 adapter

That's pointless. Foobar's DSP chain bit depth is 32 fp and it's sufficient for listening. And I haven't seen any VSTs which only capable of processing with double precision and lack usual single precision mode.

It won't be difficult but I don't see the point. Of course I will introduce double precision support if you tell me why it's necessary.

foo_vst: VST 2.4 adapter

I just tried it and it is very nice to have the ability to use multiple vst plugins at the same time.

However, in comparison to the original vst wrapper the configuration is rather tiresome: as I understand it, whenever one wants to change something, a file->preferences->dsp manager->(plugin)->configure selected is in order? The drawback with this approach is that now the "Preferences: DSP Manager" window clutters the foobar window below and cannot be closed. Furthermore, the vst plugin window cannot be minimized or put below the foobar window (all that was possible with the original vst wrapper). This means that while changing vst settings, the rest of foobar is next to unusable.

Maybe you could implement direct menu shortcuts to the configurations (like View->VST Wrapper->(vst plugin)) ? This would at least remove the locked preferences window while changing settings or using a visual vst plugin.

foo_vst: VST 2.4 adapter

That's pointless. Foobar's DSP chain bit depth is 32 fp and it's sufficient for listening. And I haven't seen any VSTs which only capable of processing with double precision and lack usual single precision mode.

It won't be difficult but I don't see the point. Of course I will introduce double precision support if you tell me why it's necessary.

It's not entirely pointless, IMO. Higher bitdepth processing will lower SNR for the particular opertation, and for processing VST that is a plus. However, for playback I doubt one can discern the difference, so not really useful is more correct. IOW, I see some points to it, but find the implementation cost is not worth the results return.

Higher bitdepth processing will lower SNR for the particular opertation

Not in this case, because there is no 64 bit chain in Foobar. One just have to decrease bit depth after increasing it anyway. Hence we get (source → N× [32 → 64 → VST single → 64 → 32] → output) in every active DSP, at every stage. It would only have meaning if there had been pure 64 bit chain in Foobar so we could do it like this: (source → N × [64 → VST double → 64] → output).

foo_vst: VST 2.4 adapter

Higher bitdepth processing will lower SNR for the particular opertation

Emphasize the bold part. I think you meant "source ? N× [32 ? 64 ? VST double ? 64 ? 32] ? output". The "VST double part" will get some benefit here, unless every VST is already using another internal bitdepth (e.g. using double precision regardless of external bitdepth). And say if you have multiple VST stacked consecutively together, it should be better if it can be done like this "source ? 32 ? 64 ? N× [VST double] ? 64 ? 32 ? output". Still I don't think the benefits are worthy of being implemented, I just wanna argue some scientific stuffs about whether this is entirely pointless.

foo_vst: VST 2.4 adapter

it should be better if it can be done like this "source → 32 → 64 → N× [VST double] → 64 → 32 → output"

Well, it can't be done in Foobar's DSP chain. There is no 64 bit datapath between DSPs in Foobar. It's not entirely pointless generally for sure. But in this particular case, as you said, barely it's worth implementing either at particular stage or in groups using some dirty trickes with storing doubles as two floats %)

foo_vst: VST 2.4 adapter

Yes, klonuo, I'm going to work on multichannel processing support soon

Quote

- it asks to restart foobar on VST removal - that is really unnecessary

Then restart on adding isn't necessary as well, is it? And restart on installation of new component unnecessary too, right? Wait, it sounds like restarts shouldn't be done at all. Something is wrong here. Let's don't confuse users and let's prevent them from using removed VSTs by restarting. If user doesn't plan to restart after removal, then they shouldn't remove. That's the ideology of Foobar's component and service system as far as I understand it. This is my way of thinking. I may be wrong. Unfortunately, there is no way to add or remove DSP services in runtime.

Quote

It loaded almost all plug ins except iZOzone4.dll although iZotope Ozon4.dll works fine.

I don't remember if previous version checks DLLs but the current one (not published yet though) explains this case clearly:iZOzone4.dll isn't VST at all. This is a shared dll which is used by both VST and RTAS wrappers.

Quote

It would be nice to be able to display multiple windows of multiple plug ins.

This is what I'm currently working on. And you know, it's quite difficult to get done because of foobar's decoupling of DSP UI and processing stuff. As I said before VST and Foobar approaches to instantiation and configuration are very different.

By the way, the VST manager is more tidy now:And it's not only about UI. Many internals have been changed to be more stable. Strict DLL checking is added.

foo_vst: VST 2.4 adapter

foo_vst: VST 2.4 adapter

@Entrase: maybe you should leave routing as is, because if i.e. I pass 6ch (5.1) stream and disable LFE then assuming you do the routing by pin activity Ls will be routed to LFE and Rs to Ls, while Rs will be muted. OTOH making some pin matrix setting could be overkill, and most importantly there is easy solution to all this. Add matrix mixer after multichannel VST and let user do the routing himself

foo_vst: VST 2.4 adapter

Even more! It looks like I'll have to leave it as is since I can't find any VST capable of reporting its output pin activity (though I haven't tested many). Even Bidule doesn't report it. So I don't know what to do with this problem. As for channel configuration, it would not be a problem in the ideal case because along with activity status there should be speaker info as well. But in fact, there is no data at all, quite often.

Quote

Plogue Bidule isn't free but you can run with full capacity for month or so without any annoying popups or similar nonsense.

Its VST wrapper is for registered users only :( I had to ask my friend to help me. I'll ask you next time instead, you'll be more responsive I guess :)

I think it won't be difficult for me to make some channel cutting DSP. Just a dialog box with a slider to set maximum number of channels. May be I'll make it inside of this component.

foo_vst: VST 2.4 adapter

Now you can use multiple DSP config windows with View → DSP menu. That's an experimantal feature and it has some bugs, but it'll take time to fix, so let's leave them till the next release.You can limit number of outputs to be taken from VST. Default setting is 6 channels (Preferences → Advanced → Playback → “Limit number of outputs for VST effects”). 16 and 32 channel Bidules should work now.VST manager internals were reworked and I had to change registry values format. Please runthis clean_vsts.reg file to remove old entries as they will crash application.

Regular members can edit their posts for 1h from the time they first publish it. You should contact some Mod and ask for promotion I think and become Developer, so that you can edit your own posts after this 1h limit. There is sticky thread in Site Related Discussion forum about this

foo_vst: VST 2.4 adapter

Yes, I know. Don't do this. It won't be easy to fix and I don't have much time these days. I'm sorry I posted such a bugged version, but hey, it's almost usable ;)

Actually, Foobar doesn't allow multiple config windows to be opened. Since these windows are modal dialogs, there can only be one in a thread. At the same time there should only be one thread—the rule I have to break. There is also no way to control window position without some kind of dirty trick. You know, I'm not sure if I should keep this feature. May be I should cut it so it will only support VST. At least config dialogs are under my control in this case.

foo_vst: VST 2.4 adapter

Actually, Foobar doesn't allow multiple config windows to be opened. Since these windows are modal dialogs, there can only be one in a thread. At the same time there should only be one thread—the rule I have to break.

Nothing stops you from having multiple threads with windows. You "just" have to make sure to properly synchronize communication between different threads and to respect the thread-related restrictions on certain APIs.

foo_vst: VST 2.4 adapter

I know. But the problem is a little bit deeper. Try to call dsp_entry::g_show_config_popup_v2 for equalizer out of main thread. It outputs “This function can be called only from main thread” to debugger (it does work however). Assuming that it's a blocking function (due to modal dialogs) and there is one main thread, there can be only one such window. If called using main thread callback, this function freezes something and prevents keyboard shortcuts from being used.