64 bit SF2 player (SFZ alternative)

[ZenPunkHippy]

That's a big question, mainly because creating a quality SFZ mapping tool like that is a huge amount of work, and beyond the scope of Alchemy 1.x. It is shame that iRompler never got past the beta stage, it had great potential.

Instrument mapping is on our list of features of Alchemy v2. Whether or not it will make the final spec is something we won't know until development starts (after 1.30 is released). It's unlikely we would develop a standalone tool, or allow exporting from Alchemy to SFZ but you never know ... personally I would like to see export implemented because it would be useful for sharing SFZ instruments.

To create SFZ files now I believe Col first creates the instrument in Kontakt 2 format, then converts the instrument to SFZ using Extreme Sample Converter. This is obviously not ideal because he's on Mac and ESC requires Windows but it works.

Peace,
Andy.

[audiojunkie]

Yeah, I agree. iRompler had a LOT of potential. I think that as far as mapping goes, SampleRobot and Chicken Systems have the best options, but at a cost.

I wish somone would create a GUI-based SFZ editor that is open to the public. The market is wide open for the individual that does this.

Until then, we have SFZed, but using it requires knowledge of the opcodes. I'm learning them little by little, but would really prefer a graphical editor.

--Sean

[solomute]

First of all I want to point out that 32-bit vsts in 64-bit daws cause latency delays. I had this problem with samplitude and thought that samplitude itself is not usuable because i had to stick to wdm to have no clicks. As soon as i had removed all 32-bit vsts from the project i noticed that all copies of native samplitude's 32-bit bridge disappeared in process explorer and i could playback with simultaneous playing midikeyboard via asia with 256 buffer without noticeable delays! Not only that was causing delays. Also some 64-bit guitar vstis. So i had to remove them as well. But what should you do with sf2 since all sf2 players are only 32-bit? As the author of the topic has noticed tx16wx is 64-bit but it's not simply unstable - it totally freezes pcs! I mean version 2 and version 1 which works well has magically disappeared from internet alltogether.
The only solution nowadays is to load sf2s via tal-sampler. Don't forget soundfonts. They are quite amazing sometimes and frequently better than huge kontakt libs which consume a lot of ram. Moreover you often will try to process those huge libs to get a kind of studio synthesized sound while that sound is already ready-made within some sf2.
I have managed to find tx16wx version 1 but only 32-bit and it sounds amazingly like true hardware... If anyone can upload tx16wx version 1 64-bit for me or share other way I would be grateful!

[Pytchblend]

Plogue's sforzando plays SF2, it's also available as a 64-bit plugin. It contains an "integrated format converter" that unpacks SF2s into samples. Plus "you can also drop SF2, DLS and acidized WAV files directly on the interface, and they will automatically get converted to SFZ 2.0, which you can then edit and tweak to your liking!" https://www.plogue.com/products/sforzando/

[whyterabbyt]

First of all I want to point out that 32-bit vsts in 64-bit daws cause latency delays.

No, they dont. Please dont necro 6-year-old threads to pass off one single anecdotal experience as unilateral fact.

I had this problem with samplitude and thought that samplitude itself is not usuable because i had to stick to wdm to have no clicks. As soon as i had removed all 32-bit vsts from the project i noticed that all copies of native samplitude's 32-bit bridge disappeared in process explorer and i could playback with simultaneous playing midikeyboard via asia with 256 buffer without noticeable delays!

So its your setup which has a problem, not bridged plugins. I can play bridged 32-bit plugins at 64-sample buffers with zero latency. In Live 10, in Bidule, in Samplitude.

Not only that was causing delays. Also some 64-bit guitar vstis.

This kind of generalisation underlines the nonsensical nature of your claim.#

They are quite amazing sometimes and frequently better than huge kontakt libs which consume a lot of ram.

More frequently, though, they're not.

As the author of the topic has noticed tx16wx is 64-bit but it's not simply unstable - it totally freezes pcs! I mean version 2 and version 1 which works well has magically disappeared from internet alltogether.

The OP posted in January 2012. Version 2 wasnt released at that point. So its V1 that he was finding unstable.

[bob bobwood]

64bit plugins that load sf2;
http://audio.rosseauxnet.de/software/plugins/sobanth/
http://wonkytop.com/javelin-vst-plugin/
http://falcosoft.hu/softwares.html#bassmidi_vsti
http://xen-arts.net/xenfont2-stereo-mic ... font-vsti/

[dnekm]

SF2 can move forward - but there needs to be some standards.....

And it has nothing to do with 32 bit vs 64 bit.

One of the things about sf2 files that strikes me is - the is no uniform to it.

Some are mono, some are stereo, some are looped, some are not.

Change the way you create them - some have the loops embedded in the source .WAV, some do not....

It is infuriating.

Some of the most well known instruments for SF2 can only use mono sources. Guenter told me that his instruments only play the left channel of stereo SF2 files....

SF2, as a container, is perfectly capable of supporting stereo sound. I have made stereo SF2's of the Anomaly soundsets - no one cared.

Because the SF2 supporting population is fragmented. Some instruments will play stereo SF2 files while the others (older ones - but well remembered and well liked) will not.

There needs to be a concerted effort by developers of instruments to support stereo SF2 files to bring this forward. It could be an alternative to SFZ. There is the ability to pack multiple .sf2's into one SF2 file. As long as you keep the file size down to a reasonable level. Remember, SF2 loading instruments can - at times - load more than one SF2 file.

Support for a stereo SF2 standard would do a world of good. And if file sizes were treated with any kind of common sense would still work in older instruments.

[solomute]

I want to point out again that any emulators including any bridges (cause bridges are emulators) create and will always create latency and that reptiloid guy lies. Also you may find articles about that matter. By that reason some companies like motu do not even implement bridges. Following the article has solved my issues and will solve for everyone. Don't use bridges because they are an additional element in sound chains and thus create latency whatever powerful pc you have! My pc is 100% stable and cpu is not even loaded to the full and it choke due to bridges. As for tx16wx I suspect that the guy was paid to stop development and issue the nonworking second version because they want sf2 to be dead because it's the past which should die. Otherwise people will think too much about things they are not expected to think about... It totally explains why version 1 is totally cleared from the net. And even from archive.org
Being quite hwlike sounding tal-sampler by that reason does not reproduce sound exactly like non-intrusive players as shortcircuit. So it's not the best substitute.
thx for advice on other choices. I am sure to try them.
I have not met across any sample converters which would convert sf2 to sfz correctly. They always spoil smth for example cut out part of attack. By that reason I never convert and try to use samplers with support of the given format.

Some 64-bit vsts create latencies. You may be lucky to fail to notice it if you have little number of tracks but if you have about 100 tracks you will immediately notice those vsts which give latency. Kontakt libs seem to be most nondelaying. Thus it's better to load more libs into kontakt vst than load vsts other than kontakt.

[solomute]

Are there any free players of akai samples?

[whyterabbyt]

I want to point out again that any emulators including any bridges (cause bridges are emulators) create and will always create latency

You are pointing out something based on fundamentally ignorance of the facts.

1) Emulation does not intrinsically cause latency. What causes latency in VST hosts is the requirement to buffer a certain amount of audio samples for audio processing eg FFT processes.
2) Bridges are not emulators. Bridges rely on the fact that an x64 processor is intrinsically capable of carrying out x86 instructions. So they launch a hosting process running in the 'other' bit mode and transfer the audio between that and the main host. Nothing is emulated, the CPU runs in compatibility mode, natively executing the x86 code where necessary. And this process has no intrinsic required buffering.

https://en.wikipedia.org/wiki/X86-64#OPMODES

and that reptiloid guy lies.

Prove it, with references.

Also you may find articles about that matter.

No, you wont.

quote]Don't use bridges because they are an additional element in sound chains and thus create latency whatever powerful pc you have![/quote]

Anyone can feel free to investigate this for themselves. Just remember that bridges cater for PDC, so report the latency of the plugins they bridge back to the host as expected.

As for tx16wx I suspect that the guy was paid to stop development and issue the nonworking second version because they want sf2 to be dead because it's the past which should die.

Conspiracy nutbaggery now? Wow.

Otherwise people will think too much about things they are not expected to think about...

That certainly describes you, kiddo.

Some 64-bit vsts create latencies.

Yes, they do. Mostly those requiring large processing buffers for FFT processes, and the occasional thing llike thru-zero flanging. That's why hosts have PDC. Almost unheard of in synth plugins, though.

You may be lucky to fail to notice it if you have little number of tracks but if you have about 100 tracks you will immediately notice those vsts which give latency.

Not where PDC would be operational, though.

Kontakt libs seem to be most nondelaying.
Thus it's better to load more libs into kontakt vst than load vsts other than kontakt.

Your comments seem to resemble superstition more than they do facts. Whilst its entirely possible for a VSTi to have latency, its almost unheard of. Kontakt has the same absence of latency as almost every other VSTi out there.

[whyterabbyt]

SF2 can move forward - but there needs to be some standards.....

Well, strictly speaking it is already a standard

And it has nothing to do with 32 bit vs 64 bit.

Indeed not.

One of the things about sf2 files that strikes me is - the is no uniform to it.

Some are mono, some are stereo, some are looped, some are not.

Change the way you create them - some have the loops embedded in the source .WAV, some do not....

It is infuriating.

Well, that's because ithe standard allows those things within the file format, but the standard doesnt proscribe the useage of that file format.

Because the SF2 supporting population is fragmented.

That's more the point; the useage of the file format varies. But would developers really want to use a file format that locked you down on all those things?

There needs to be a concerted effort by developers of instruments to support stereo SF2 files to bring this forward. It could be an alternative to SFZ.

But that's kind of bizarre. SFZ is the alternative to SF2; that's its purpose, that's why it was created. An easier, more consistent, human-readable, esaily-edited, open alternative to SF2. The only 'advantage' SF2 has as a format spec is the monolithic file, (and actually a zipped sfz folder could be used as a pseudo-monoloth if devleopers wanted to go that way.)

Anyway, that's getting away from my point. sf2 was an 'unfortunate' standard in some ways, and that's what causes issues like these in the first place. To my mind it would be 'better' if sfz had 'taken over', but of course standards never replace each other, they just compete. ( I do suspect that if sfz had existed as a format when Jeff McLintock was writing Synthedit, he'd as likely included support for that than sf2, and SE developers would have had more options available to them.)

Thinking about it Im kind of surprised there isnt already an sfz parsing library out there for developers. Guess it depends too much on the plugin's data architecture.

[solomute]

PDC plug delay compensation works very poorely and does not work on most old 32-bit vsts including genwave eq. There is some voxengo plugin promised to fix the problem of vsts not reporting latency to pdc host's feature and yet that plugin is totally crap and does not work. Ddmf metaplugin also fails. Asio4all fails, etc. All this pdc is more a theoretical thing than working solution to keep ignorant users calm. Secondly pdc does not correct midi input latency, it kind of tries to compensate only playback.
Whatever causes the delay emulation or not but I insist on not using bridges and search for articles yourself. It helped me greatly. Now I am restructuring my workflow for 64-bit only. Otherwise your workflow will be very slow. But speed if very important!

THere is little number of sfz libs which renders this format promising but useless and not many people willing to create new sfz libs. Another matter is sf2. Sf2 are usable only for synth sounds. As for kontakt, when you load all into one vst you have less competing processes than using many vsts, there you have smaller latency. Also kontakt use seems to be optimized by daws' manufacturers while other vsts can be even secretely blocked.
Most vsts don't use fft. Fft-based vsts are rare and considered high class. Vstis based on samples do not use any calculation at all and by the way those samples-based 64bit vsts were giving the greatest delay. Some of them even freeze pc for several seconds when you open their gui.
You will find some artictles about setting up windows for realtime audio. They may fail to help you if you are using 32-bit vsts via bridges.

[Jace-BeOS]

Conspiracy nutbaggery now? Wow.

Well, he did call you a "reptiloid"...

Your comments seem to resemble superstition more than they do facts.

Conspiracy theorists live in the thought mode of superstition.

[whyterabbyt]

Conspiracy nutbaggery now? Wow.

Well, he did call you a "reptiloid"...

good point. extra nutbag points, then.

[whyterabbyt]

PDC plug delay compensation works very poorely

False. PDC works fine where implemented properly on both host and plugin.

and does not work on most old 32-bit vsts including genwave eq.

False. The only responsibility a plugin has with regard to PDC is to report its latency correctly. Funnily enough, that's not something which correlates with the processor instruction set its running.

There is some voxengo plugin promised to fix the problem of vsts not reporting latency to pdc host's feature and yet that plugin is totally crap and does not work.

False. There's a Voxengo plugin which assists in compensating for plugins which do not report latency properly, which is a different thing. It does exactly what it was designed to do.

Ddmf metaplugin also fails.

That assertion makes no sense in this context. Metaplugin has no facility for resolving plugin PDC issues.

Asio4all fails, etc.

That assertion makes no sense in this context. ASIO4All has nothing to do with PDC.

Are you sure you're not conflating PDC with plugin buffer sizes or something else completely unrelated? It certainly seems that way.

All this pdc is more a theoretical thing than working solution to keep ignorant users calm.

False. PDC is a technical solution to the problem of resolving plugin latency, and almost all hosts have implementations to one degree or another. There's nothing 'theoretical' about it, and only a user ignorant of how it works would claim that.

Secondly pdc does not correct midi input latency, it kind of tries to compensate only playback.

There's no 'secondly'. Plugin delay compensation is what it is, and it has nothing to do with MIDI at all. Only a user ignorant of what it is and how it works would relate PDC to MIDI input latency.

Whatever causes the delay emulation or not but I insist on not using bridges and search for articles yourself.

No-one cares how you choose to work. However your conflation of unrelated causes and effects will continue to result in people correcting your underlying ignorances.

Also kontakt use seems to be optimized by daws' manufacturers while other vsts can be even secretely blocked.

Extraordinary claim, requiring extraordinary evidence.

Most vsts don't use fft. Fft-based vsts are rare

True. Its also true that most plugins dont induce latency.

and considered high class.

False. FFT is a method of calculation, it has no intrinsic correlation with 'class'.

Vstis based on samples do not use any calculation at all

False. Plugins would be unable to produce audio if they did no calculations.

and by the way those samples-based 64bit vsts were giving the greatest delay.

That assertion contains insufficient content. However, since VST plugins have no requirement for inducing actual latency, and you have very ppor grasp of the technology, t seems likely that something else was occurring (badly written plugins responding slowly, for example) and that you are conflating that with plugin latency.
Without specifics though, this is merely anecdote.

You will find some artictles about setting up windows for realtime audio.

True. Many, however, are out of date, or flawed.

They may fail to help you if you are using 32-bit vsts via bridges.

True. Bridging would be unrelated to optimisation.