Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_vst: VST 2.4 adapter (Read 522330 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

foo_vst: VST 2.4 adapter

Reply #50
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

Reply #51
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.


So, something circular buffer related.

foo_vst: VST 2.4 adapter

Reply #52
Will there be support for 64-bit VSTs?

I think noiselab means support for x86 VST plugins with 64-bit datapath (double instead float).
Not 64-bit code plugins compiled for x86_64 ...

foo_vst: VST 2.4 adapter

Reply #53
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

Reply #54
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

Reply #55
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.

foo_vst: VST 2.4 adapter

Reply #56
Quote
Maybe you could implement direct menu shortcuts to the configurations (like View->VST Wrapper->(vst plugin)) ?
Quote
  • Multichannel setup arrangement differences aren't taken into account, nor is VST pin activity status
  • No support for plugins without GUI yet
  • Configuration windows only work in modal mode
  • z3ta_fx and IXL analyzers crashes the application

All of these are to be fixed soon.


Quote
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

Reply #57
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

Reply #58
Quote
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

Reply #59
  • Multichannel setup arrangement differences aren't taken into account, nor is VST pin activity status

To sustain that theory, I did some simple testing for multichannel VSTs not knowing your OP screenshot multichannel VSTs

), but your component I guess tries to output 32 channel and foobar can't handle it
[a href="http://i56.tinypic.com/35ausf7.png" target="_blank"]

[edit] changed 16 to 32 to match screenshot, as there are three bidule VSTs - standard, 16 ch and 32ch

foo_vst: VST 2.4 adapter

Reply #60
Hi Entrase, your VST plug in is great !
It loaded almost all plug ins except iZOzone4.dll although iZotope Ozon4.dll works fine.

I am wondering if you plan to release new version after 2011/Jan/01.

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

All the Best

pjofoobar


foo_vst: VST 2.4 adapter

Reply #61
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.

Thank you guys. Working hard.

foo_vst: VST 2.4 adapter

Reply #62


Coming soon... :)

foo_vst: VST 2.4 adapter

Reply #63
What about no reload track switch, I'm waiting for this .

foo_vst: VST 2.4 adapter

Reply #64
@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

[a href="http://i51.tinypic.com/2iual9k.png" target="_blank"]
* that's why hosts like Bidule can be very handy (not mentioning it's real powers inside)

foo_vst: VST 2.4 adapter

Reply #65
Quote
What about no reload track switch, I'm waiting for this
Yes, sure. As soon as current UI mess is done.

Quote
maybe you should leave routing as is
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

Reply #66
Update
Please re-download the archive.

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 run this clean_vsts.reg file to remove old entries as they will crash application.

Finally marked as beta now.

foo_vst: VST 2.4 adapter

Reply #67
Please update the first post with changes instead and include the reg file and instructions with the main archive since it looks like it might be needed for every update. Thank you!

foo_vst: VST 2.4 adapter

Reply #68
Please update the first post with changes instead and include the reg file and instructions with the main archive since it looks like it might be needed for every update. Thank you!
I can't.



Should I always provide moderator with updated texts and ask them to update or what? How is it established here?


foo_vst: VST 2.4 adapter

Reply #70
16 and 32 channel Bidules should work now.

Thanks Entrase
Having foobar environment with multichannel Bidule processing feels like advanced possibilities can now easily be adopted to any file:

[a href="http://i51.tinypic.com/2vl5n3o.png" target="_blank"]

I can't.


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

Reply #71
@Entrase: Try to load same VST twice (in VST listing)

foo_vst: VST 2.4 adapter

Reply #72
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

Reply #73
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.
Just to clarify: The restriction about modal windows is not imposed by foobar2000, it is inherent in Win32 programming. Raymond Chen has written several times about this issue in his blog.

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

Reply #74
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.