Windows beta pre-release (incl. VST and 64 bit binaries)

[sbenno]

I'm not convinced of that multi-DLL approach. I would simply make it configurable. By default 2 channels and the user could override it either with JSampler / QSampler or a separate app which we could include in the start menu entry. After the user changed the setting, he has to restart the plugin and he would have the desired amount of outputs.

Of course it would be better to make it configurable, but the question is what if the need arises to work with 2 instances at the same time, one with 2 channels and the other with 16 ?
The question is why Kontakt is using this approach (one DLL with 2 output channels, one with 16 outs). Was NI just lazy or are there cases where the user purposely wants to use the two DLLs at the same time ?

or one could implement cuse's suggestion by providing a config file for each DLL.
for example
linuxsampler.dll (2 outs)
linuxsampler.dll.conf is a textfile that contains
outs=2
(amongst other parameters if needed)

linuxsampler_16outs.dll (16 channel version)
linuxsampler_16outs.dll.conf contains
outs=16

that way the user can simply create as many DLLs he wants and using them all at the same time.
just copy the DLL with anothert name, create the config file, set the number of outs. (could be done via editor or by external app)

then at load time the DLL just looks for a file DLLNAME.conf and reads the parameters from that file and sets the numbert of outs.


what do you think cuse ?

ggoodesa: using VST DLLs with many output channels could decrease performance due to more memory copying operations. the DLLs does not get bigger or uses more memory though.
Therefore ideally we should just use as much channels as needed.

[typewriter]

A 16 channel version of LS would be nice. Perfect for using LS on one Reaper track with 16 Midi channels. I guess 16 channels are sufficient for most applications since there is still the possibility to insert another instance like it was the case with Tascams GVI.

[cuse]

Of course it would be better to make it configurable, but the question is what if the need arises to work with 2 instances at the same time, one with 2 channels and the other with 16 ?

Well, in theory.... but in practice do you really expect somebody to insist on using a 2 channel instance and a 16 channel instance at the same time? I'm pretty sure he would be also just fine using then e.g. two instances with both 16 channels. A simultanous 2ch and 16ch instance solution would only be required for people who push their system _exactly_ to the limit.

The drawbacks of having more (unused) output channels:

• Slightly more CPU usage, as the audio buffer of each audio channel has to be reset to zero (memset(pChanBuf, 0, bufsize)) once each audio cycle, but that's a very fast operation.
• Slightly more memory consumption (RAM): no_channels * period_bufsize (in practice 16ch vs 2ch: +6 kB ... +500 kB).

Again, I'm talking about more unused audio output channels. When those additional audio channels are in use, memory and CPU consumption will of course be a lot higher than written above, but we're just talking about the drawbacks of a plugin version with more unused audio channels.

Drawbacks of using multiple DLLs (e.g. a 2ch DLL and a 16ch DLL):

• Slightly more memory consumption, because e.g. when using a 2ch and a 16ch plugin DLL at the same time, both DLLs have to be loaded into RAM (each plugin DLL occupies about +300 kB ... +700 kB).
• Slightly more CPU usage (probably), as the two plugin instances don't share the same code segment, thus there will probably be more cache misses regarding the code segments.

So I think this whole issue is not worth all the hassle. Probably the Kontakt guys provide multiple plugin DLLs, as for each VST plugin instance a new instance of the Kontakt instance is created, so I guess the resource overhead is higher in their case. So lazyness could also be a big factor there.

or one could implement cuse's suggestion by providing a config file for each DLL.
for example
linuxsampler.dll (2 outs)
linuxsampler.dll.conf is a textfile that contains
outs=2
(amongst other parameters if needed)

linuxsampler_16outs.dll (16 channel version)
linuxsampler_16outs.dll.conf contains
outs=16

that way the user can simply create as many DLLs he wants and using them all at the same time.
just copy the DLL with anothert name, create the config file, set the number of outs. (could be done via editor or by external app)

You expect Windows users to copy DLLs and edit config files with a text editor? Remember that recently Windows users complained about things like that they have to find and klick on the "Screenshot" and "Download" button on the left of our website and said we should have screenshots and direct downloads on the frontsite instead. And you think they would be pleased about such a solution?

I think that would be unintuitively, misleading and chaotic.

[typewriter]

So I think this whole issue is not worth all the hassle. Probably the Kontakt guys provide multiple plugin DLLs, as for each VST plugin instance a new instance of the Kontakt instance is created, so I guess the resource overhead is higher in their case. So lazyness could also be a big factor there.

As far as I recall each additional kontakt instance uses over 100MB or more RAM. So a memory overhead of 500kb with linuxsampler is a joke compared to that. Go for a 16 channel version. This would be the perfect number if a sequencer track can address 16 midi channels at the same time like Reaper. Featurewise LS is nearly complete. The only thing I could think of would be midimaps that are saved within the plugin status. A little bit distracting are the channel numbers ranging from 0 to 15 in a 16 channel plugin because hosts do not start counting with "0". Being able to "label" a channel, e.g. with "violins" especially when there are articulations switches with midimaps would be a plus in my opinion.

One last question: What happens when a second 16 channel plug is inserted? Another fantasia instance or fantasia with 32 channels?

[grishata]

If I'm not mistaken, trying to load another LS dll will fail, because it will try to bind to port 8888, which will be taken by the first one. The plugin will also fail if you have LS started as a standalone app before that, or if you have LS plugin loaded in another host app. Maybe we should think about using dynamic ports and a way to inform the front-end to which port to connect when LS is loaded as plugin...

[ggoodesa]

Looks like a build of 16 channels is the way to go... less complicated for the end user. Perhaps this can just be a 'compile-time' setting so that those who really want to tweak there systems can do so? My 2c
Oh, and in the final release of the Windows release, would it be possible to build with both ASIO and JACK Audio device support? More options I know, but greater flexibilty too...

And what were the compile time options of this windows beta build? --enable-refill-streams=2 --enable-stream-size=320000 --enable-preload-samples=65536?

Thanks guys!
GrahamG

[typewriter]

Looks like a build of 16 channels is the way to go...

I think so, too. We are talking about 16 stereo channels, right?

[cuse]

Oh, and in the final release of the Windows release, would it be possible to build with both ASIO and JACK Audio device support? More options I know, but greater flexibilty too...

Of course we could compile the release version with JACK support, but the effort to support JACK cleanly with a windows installer is probably a bit higher than you expect. The problem is, the JACK driver in LS will only work with the JACK version it was compiled against. And as all drivers are currently compiled into liblinuxsampler the whole application would refuse to load in case the user doesn't have a compatible JACK version installed. So first we definitely would have to change the driver concept, so that all drivers are split into DLLs, loaded at runtime by liblinuxsampler (similar as we do it for the instrument editor plugin(s)). But that just solves the problem that LS wont start if the expected JACK version isnt there. Yet you won't be able to use JACK with LS as long as you don't have a compatible version of JACK installed. So what shall we do about the JACK version dilema in general? Ship our own version of JACK with the installer? But then some people prefer the old (standard) C JACK and others prefer Stéphane's new jackdmp (the latter has SMP support). And of course some might already have a JACK version installed.

So even though we have full support for JACK on source code level, it's quite tricky to support it cleanly with a Windows installer. And the question is, is that effort really worth it ATM? What JACK-capable apps do you use under Windows already?

Of course it would be nice to have JACK support with the standard Windows installer, but considering the amount of effort it would take, maybe its better to spend that time on other things at this point.

[ggoodesa]

Hi,
I didn't know that the versioning with jack was an issue (and I've only ever used jackdmp/jack2 in Windows - I don't know if there is a Jack1 build for windows out there...). I did a compile with the Jackdmp 1.9.1 headers/libs and it worked so well that I thought it would be simple to just include it. As it is not, then I'm happy compiling my own with Jack and ASIO and letting others stay with just ASIO and able to use the JackRouter ASIO driver if they want to use Jackdmp.
I currently only have fluidsynth and linuxsampler with native Jack, everything else uses the JackRouter ASIO driver.
GrahamG

[yogi_loeschner]

Hi,
I tried out the VST-Plugin with Sonar 6.2. My soundcard is an Audiophile 2496 and old Audigy (to get the audiophile audio to my speakers). Whenever I reload a project in Sonar that used Fantasia, it shows me the "Applying global stream/voice limits"-window with loading bar forever. However the samples are already playable then.

Another problem is, that I cannot use LS for staccato sequences...it always takes a while until the same key can be played again. I didn't dig too far into it, but I guess it's a voice count problem. Any thoughts on that?