Output formats in the pro version - saving SFZ

Official support for: tx16wx.com
Post Reply New Topic
RELATED
PRODUCTS

Post

For version 1.0 I work on the right flow while loading complex sfz to tx16wx and then converting txprog back to sfz...

I implemented an open UTF16 file converter by "trogluddite". That makes (the way I build it in) tx2sfz much more reliable!

Loading them back in tx16wx works now fine, because TX16WX takes the rootkey ALWAYS from the sample wavs... but using the sfz file in an sfz player leads to completely messy tuning...

I will ask the developer of Tx16Wx for an option to convert rootkey wav reading to transpose, turning off wav reading...

Post

O.K. So far I have a workaround for the wavheader reading problem (don't know if I'm able to solve it): Just imagine, you put 30min of work in a complex Tx16Wx instrument that you want to use as SFZ too.
1. Take tx2sfz and convert.
2. Take Bjoerns Sample Mapper & let ad the rootkeys, loop info etc.

Voila!You should have a nice SFZ instrument. I just experimented with it and got a very goodlooking result, but I did not test it so far!

It should work and is just a few seconds to convert a program for which you used some time...

Now I have a reliable version 1.0 here with some extra settings, but I will give it some time. Maybe I will be able to manage that rootkey reading somehow...

Post

I hope, this is worth a 1.0 beta

www.derknott.de/tx2sfz.zip

(no rootkey from wav reading so far, but option to set no rootkey, if your sfz player reads it from wav or to set hikey as root & the possibility to use a global transpose, to get it right, if you are using same distances from rootkey to hikey for all zones which should be quite usefull in many situations)

(it isn't possible anymore to set save dir because it has to be input dir anyway, but there's an option to set an own name for the sfz program)

*now corrected transpose bug

Post

This is really what has been missing from the TX16Wx VST: a good SFZ format export. If the idea behind TX16Wx is to provide an "open source" kind of workhorse, using an "Open, Documented File Format" (quote), then not being able to save to this format is a big miss, it seems to me.

I've been looking myself to get a good sample editor to save to SFZ format, as I believe it's indeed the most universal format, since it allows me to have a bunch of raw WAV files and do whatever I like with it, without ever touching their integrity or adding bulky files to their folders. On the other hand I end up with files that I can load in most major samplers, including funky ones like Alchemy and Zampler, without a sweat.

So thank you for your work, mmcy, this is really a most welcome addition. Although it's possible to edit SFZ files in a text editor, creating the output file with the possibility to tweak knobs and arrange keygroups in a handy window sure beats it!

Still, I think there's a long road ahead, as I'm sure you realize. Maybe you could get some help from other developers?

Some issues I may point out that I hope will be useful:

* The GUI needs lots of work, not just for esthetic reasons, but for usefulness. With my resolution settings, the text is a few notches too small. It should be set to at least a standard 10 px or bigger (instead of the 7.5 px or so it looks to be), or it should be possible to resize.

* Once in the application, having to copy bits of code from "yellow" to "blue", is messy and complicates matters by default. All that coding stuff should be way more automatic for the converter to be nice to use frequently.

* When trying tx2sfz on a 1 sample program, I tried a few filter settings, none of them appearing even in the yellow files.
The volume transfer is also a problem, as you've pointed out. Had to fix it in the text editor.

There are actually TONS of parameters that can be contained in the SFZ format (I guess you've seen the file at http://www.cakewalk.com/devXchange/article.aspx?aid=108 ), so I realize it's going to be quite some work to get a version that will transfer at least the basic parameters flawlessly.

Much luck with it, and hopefull some other developers will jump in on this! Even better: why not make this is standard feature for this sampler? It would certainly be a reason for me to purchase the pro version. An export to SF2 format will also be very useful since quite a few interesting VSTs use it (even though it's a format that can result in bulky files) - I believe I read somewhere this is planned for the Pro version.

Take care ;)

[Edit: removed a comment concerning a release parameter, which I oversaw in the output file]

Post

Thank you so much for leaving your impressions!!!! I really need that. Otherwise it makes no sense uploading something.

The volumebug and a few other things are corrected since some days... Whenever a day has passed everything seemed so easy although it wasn't the other day :-) I just wanted to upload the newest version with wav-root-reading...
It seems I'm so damn near getting it to work as I want, but I hesitate uploading v.1.1. It's getting better with every week, so stay tuned!
I guess it will be up this weekend.

- the yellow to blue stuff :-) is just for group settings, to have some more flexibility. It is planned to let the software recognize more parameters automatically... Sadly with some last changes it has become a bit complicated, as I work like in an experimental lab. Maybe I'll rewrite the whole program for version 3.0, but maybe not. I will be happy with just basic parameters, but it's tempting to get out the most of it!

b.t.w. with documented file format he was talking about his own format (txprog) I think. That's the reason I could build this so 'easily' ... no it wasn't easy (because I'm no programmer), but fun!

Post

you can create sfz with my little program :
http://carrieres.free.fr/sfz.htm
Image

Post

Much improved version under

http://www.derknott.de/tx2sfz.zip

This is exactly what I hoped to be able to build and I have that feeling, that I nailed it :-)
The wav-root reading makes everything easy and reliable.

Now I only have to add some more parameters.

Post

carrieres wrote:you can create sfz with my little program :
http://carrieres.free.fr/sfz.htm
That's what I used before... But now everything becomes so beautifully easy!
(it was before, using your prog, for percussion banks etc...., but building an instrument, while listening to what changes while constructing is possible with TX16WX and then converting to sfz is as easy as starting tx2sfz and opening & saving...

Post

from naive reading I should be able to read the following things from tx16wx program file on a per group basis (so for each sample, as you follow my hint to split all groups in TX16WX before converting):

(List of parameters I did not implement so far, but which should work without bigger problems:)

- Filter type (makes sense, but I mostly use it as group parameter anyway or in a sampler like TX16WX or shortcircuit, which have nice handling of that anyway. There's no real reason for me to have that in the sfz file, although of course: everything that works is nice!)
- resonance (same)
- filter frequency (same)
- adsr (makes sense and will make it more complete)
- velocity parameters (makes sense)
- START offset (hopefully will ad that soon!!!)
- choke (what exactly was it, sorry, will take a look at it :-))
- env parameters (at some point it just makes sense to use TX16WX as it is, with all its great possibilities, without exporting as sfz)
- lfos (no need for me..., but maybe they'll follow)

- tx16wx saves end & loops in the wav file. "Bjoerns sample Mapper" is a great software to handle them and ad them to the allready converted sfz in a second. So no need for me to do lots of extra hours of work.

If I get some of these working it's far more than I originally planned & need for myself. I'm just happy, to have the basic structure available in SFZ.


Martin

*** edit: A,H,D,S,R,resonance, cutoff, playmode, startoffset are now integrated, but NOT uploaded so far. Too much code to be without bugs :-) ***

Post

mccy wrote:
carrieres wrote:you can create sfz with my little program :
http://carrieres.free.fr/sfz.htm
That's what I used before... But now everything becomes so beautifully easy!
(it was before, using your prog, for percussion banks etc...., but building an instrument, while listening to what changes while constructing is possible with TX16WX and then converting to sfz is as easy as starting tx2sfz and opening & saving...
i get it now ! it's simpler and awesome with your software
congratulation !
Image

Post

mccy wrote:Much improved version under

http://www.derknott.de/tx2sfz.zip

This is exactly what I hoped to be able to build and I have that feeling, that I nailed it :-)
The wav-root reading makes everything easy and reliable.

Now I only have to add some more parameters.
Thanks! My eyes thank you for making the text larger :-o

mccy, I'm not sure how far you want to take programming and to what extent you wish to create something that will be genuinely reliable and hold up over time. The way it is now, this little application will already be very useful! However, I can't get any useful SFZ out of it without having to tweak in a text-editor just about every line of code of the final output file. The only bits of a TX16Wz program that I get succesfully converted are the codes defining what sample is used, and their key-range (but not for every sample-player, see what follows). After trying out all sorts of things, I found I had to clean up and modify just about anything else... :( So, still lots of things have to get fixed, although of course, I don't know what you have in store for the moment...

See, before I found tx2sfz, I tried to convert sample programs to SFZ using Highlife. But it converts a program into an SFZ by resaving all the samples, with new names, which results in unnecessary extra bulk. It also uses the old SFZ format v1. With that, it is also giving some bugs in the DAW I use (Presonus Studio One), albeit minor ones. Still, the SFZ files it generates are fair and useable. More importantly, they don't actually need to be tweaked to be used.

Now I have to choose between software that generates SFZ files that has to be tweaked all over the place, or software that is alright (be it slightly buggy), but generates extra bulk and would benefit from some tweaks.

If you want this application to be used by many, I believe you should make it so that the default settings will always result in a SFZ file without glitches, ready to be used in say (at least) SFZ Sample Player (by Cakewalk), Sforzando and Alchemy. Dimension Pro would be another good one, but has to be bought. SFZ and Sforzando don't really add anything of interest at present, soundwise, so the more important one is Alchemy, next Zampler, and so on. Presently, the generated files don't work in them (usually).

Preferably, output SFZ files should also work when imported back into TX16Wz, but I found that importing SFZ files into TX16Wz is often not working properly, as things are right now, duh... elcallio, you might want to check things loading the reference files at
http://www.cakewalk.com/DevXchange/file ... 0tests.rar
as found at http://www.cakewalk.com/DevXchange/article.aspx?aid=118

I'll describe some issues I found when working with tx2sfz. Many details have been left out, such as to not make this post too bulky. mccy, if you want me to, I can give more specific details and even upload some files to illustrate them.

Issues:

> tx2sfz generates no default value for " pitch_keycenter ". This results in an error when loading a SFZ file created by tx2sfz into Sforzando.

While tx2sfz doesn't set a value for pitch_keycenter in the SFZ output file, and while it doesn't show up in any of the blue and yellow fields, the output SFZ file does include the code for it (but blank). Weird... Needs to be fixed.

> It appears that Alchemy and Zampler don't use the "Transpose" field. So better don't use that. To make SFZ files compatible with these samplers/synths, only the correct "pitch_keycenter" should be given for getting the right pitch (also see other comments that follow concerning this piece of code).

I understand that it can be maddening to see how various samplers/synths set/read the root value of a sample. To complicate matters further TX16Wz offers several options to organize pitches of samples. Nevertheless, I guess you'll best set a default setting that is so basic that it will be understood by the most prominent samplers/synths.

Test this out by loading the result in the various samplers/synths!

> When testing SFZ files in the SFZ Sample Player by Cakewalk, I found that it doesn't load "lokey" and "hikey" input in note names. It understands only note numbers!

So to use a sample over an entire keyboard range, these values should be set as follows:

lokey=0
hikey=127

tx2sfz presently outputs note names, so this has to be fixed.

> When testing some drum sounds with fixed pitch for every sample and key-range, I noticed the keytrack coding was incorrectly read by tx2sfz. It read pitch_keytrack=100 from the TX16Wz file, but it should have been: pitch_keytrack=0

Also, it ( pitch_keytrack ) appears in the <group> section, not in the <region> section where I believe it should be, since one might want to assemble a program that has some samples (i.e. keys) play at a fixed pitch, and other samples with normally transposed pitches. But OK, that's an advanced use..., can work around that.

This issue is further complicated by the fact that tx2sfz changes (TX16Wz) groups into (SFZ) regions. See comment below. May need to be looked into...

> Another value that is (still) not correct by default, is the volume. I don't understand why setting it to "0" in the menu in the top bar doesn't set it at 0 but to -6.93 (in my case), nor why setting it at "+6" doesn't correct it to a final setting of 0dB.

> Apparently, filter settings are VERY difficult to convert properly. And I found that from the samplers/synths I tested, only SFZ player and Sforzando import some filter setting, but only when coded meticulously.

To keep this brief: any further tweaking of how tx2sfz handles filter settings should be tested thoroughly by loading the end-result into various samplers/synths!! None of the default conversions worked for me.

If you want me to give more details/suggestions, let me know...

> When in tx2sfz clicking on the text field, the text turns smaller and reduces to one single line. Weird. To return I have to click on the window edge.

By the way, it would be handy to have this field as easy to use as a text editor like Notepad or Vim/gVim, with the possibility of direct text input, since the idea is to try out different settings.

> After working on a certain file, when loading a new TX16Wz file into tx2sfz, blue fields that contain codes copied from the yellow fields are NOT reset (to blank). Weird. Good reset operation needed.

> Should it be necessary to save a TX16Wz file with all its content, as stated? It doesn't seem to be really necessary, nor should it be, unless one plans to use the SFZ file in a different folder than the TX16Wz file. I had no problem at all related to working with a file that was NOT saved with all its content.

> You mention (in the tx2sfz window) that before loading a TX16Wz file into tx2sfz, all "Groups" should be saved into "single sample groups". Is there a quick button for that in TX16Wz?

It seems that separate "Groups" of the TX16Wz file end up in "Regions" in the converted output SFZ file. Weird... Even weirder, when loading some of these SFZ files with different regions back into TX16Wz, these get grouped into separate groups! I got this when converting a simple velocity-layered setting. Samples got grouped by their velocity range, not their key range. Duh...

> When importing a file into tx2sfz, why is the code "ampeg_release=..." by default only in the 9th field? Why not in the 2nd?

> It would be useful to have an undo function for at least one past action, such as for incorrect paste or text input.

> It would be useful to have a little help file (PDF?), in which some of the functions and menus are described. Be sure to include a description of all the menus of the top bar, and what settings to use. For example, what "root" settings should be used (and why/when)?


All in all, mccy, the default SFZ output should clearly be tested in at least a number of other samplers/synths. Sforzando is a good reference, but things should also work especially in Alchemy and Zampler, and before all also in SFZ Sample PLayer, as that is from the SFZ format inventors. Maybe the present version of tx2sfz is easy for you to work with, but having to tweak just about every line of code to do a good conversion will be problematic for most.

This doesn't mean tx2fz should transform ANY parameter available in TX16Wz. After all, the usefulness of other samplers is precisely that they are different. And each sampler/synth uses a selection of different parameters. So just covering the basic (useful) parameters will do a great job. Getting them right from the outset will be even better.

As an example, I found that Alchemy only has a limited number of parameters it can read from a SFZ file, which are given at http://www.camelaudio.com/alchemymanual/source/import/

These are:
Alchemy recognizes the <region> and <group> headers and the following opcodes:

sample
pitch_keycenter
key
lokey
hikey
lovel
hivel
loop_mode
cutoff
fil_veltrack
tune
volume
pan
seq_position
trigger
sw_last
default_path
On that page, it also says the following:
NOTE. Alchemy prefers SFZ files that contain note numbers (e.g. hikey=54) rather than note names (e.g. hikey=f#3), to always remain compatible with both MIDI note 48 and 60 middle C, note number conventions, and to avoid any octave jumps around middle C.
This issue also arose for the SFZ Sample player. So something to take note of!

As a final suggestion, while it will be the most useful to have default settings that will result in a good universal SFZ file, it may be useful and/or necessary to make it optional to choose certain settings, though surely not for all the cases in the present version. Maybe instead of using the colored fields, you could change this into a setup where the user can select something like: "include code = yes/no". But this should be limited to as few instances as possible! Anyway, just an idea...

Hopefully, all this is not too much comments for you to deal with, and that it will help to put together a nice update! As it's only your first attempt at writing a piece of software like this, it's only understandable that it will take some work and reflection to get it right. Also, take an extra look at the SFZ reference files by Cakewalk (see links at beginning of post), to check how things should look.

Take care ;)

Post

Great!!! I just need such observations, to get better! If I do not answer everything that is just because I have enough input so far, but I want it to get better & better so at a point I will love to doublecheck all of your points!!!
1. For now I in most cases just test sforzando. I have to start somewhere. I think I will do that until I'm ready for myself. I have a last very ambitious project (although I did not upload the last one so far): I want it to read the SFZ-usefull settings in the modulation matrix. I want to have fun with pitchchanging drums and per-sample-filtermovements. It should be possible... For me, as allways, it's a bit more work, as this is not my usual buisness.


Sounddigger wrote: See, before I found tx2sfz, I tried to convert sample programs to SFZ using Highlife.
Ah, I allready used it too. It's nice, but far away from being perfect,yes!
Sounddigger wrote: If you want this application to be used by many, I believe you should make it so that the default settings will always result in a SFZ file without glitches, ready to be used in say (at least) SFZ Sample Player (by Cakewalk), Sforzando and Alchemy. Dimension Pro would be another good one, but has to be bought. SFZ and Sforzando don't really add anything of interest at present, soundwise, so the more important one is Alchemy, next Zampler, and so on. Presently, the generated files don't work in them (usually).
I don't know Alchemy & Dimension. I like Zampler. I'll do my best, to extend testing... From first reading the things you mention should all make sense to me, so we look into a bright future, I hope :-)
Sounddigger wrote: Preferably, output SFZ files should also work when imported back into TX16Wz, but I found that importing SFZ files into TX16Wz is often not working properly, as things are right now, duh...
Oups, I first tested TX16Wx, but then found it to make more sense to test with sforzando.

Aaah, by the way: There is one BIG drawback with tx2sfz & sfz sampling: You won't be able to use other files than wavs... That is a problem for me so far I can't solve... But let it take another months and I will look into it again.
Sounddigger wrote: > tx2sfz generates no default value for " pitch_keycenter ". This results in an error when loading a SFZ file created by tx2sfz into Sforzando.
I wonder about that. Will have to check it again. That was just my last big project, enabling wav reading for rootkey. There are 2 other options to set root key: highkey = rootkey and no rootkey... So I hope there is no bug with "no rootkey"...
Sounddigger wrote: in any of the blue and yellow fields,
I should have removed those blue & yellow fields first... They are just Group parameters that you can type in manually. (you can type whatever you want) They have nothing to do with the sample - groups.
Sounddigger wrote: > It appears that Alchemy and Zampler don't use the "Transpose" field. So better don't use that. To make SFZ files compatible with these samplers/synths, only the correct "pitch_keycenter" should be given for getting the right pitch (also see other comments that follow concerning this piece of code).
Hmmmm. I like the transpose opcode. I will have to think about it. But in fact it should not be necessary by now.
Sounddigger wrote: > When testing SFZ files in the SFZ Sample Player by Cakewalk, I found that it doesn't load "lokey" and "hikey" input in note names. It understands only note numbers!
That makes absolute sense. It is just as much mork as typing all notenames counted from 0-127 to an array and then convert. This is a must feature. Thanks.
Sounddigger wrote: > When testing some drum sounds with fixed pitch for every sample and key-range, I noticed the keytrack coding was incorrectly read by tx2sfz. It read pitch_keytrack=100 from the TX16Wz file, but it should have been: pitch_keytrack=0
That's exactly, why I introduced the blue & yellow fields: For drum programs you have to change it to 0. It reads NOTHING from Tx16wx in this case. It is just an option to change group opcodes manually, because so far tx2sfz does not read pitch-keytrack, as there is no parameter like that in tx16wx, although i could translate normal & fixed & maybe some other scales to pitchtrackings.... O.K. that's possible, I think.
Sounddigger wrote: Also, it ( pitch_keytrack ) appears in the <group> section, not in the <region> section where I believe it should be, since one might want to assemble a program that has some samples (i.e. keys) play at a fixed pitch, and other samples with normally transposed pitches. But OK, that's an advanced use..., can work around that.
I never did, so it's of course advanced. But maybe I will :-)
Sounddigger wrote: This issue is further complicated by the fact that tx2sfz changes (TX16Wz) groups into (SFZ) regions. See comment below. May need to be looked into...
That's a big one. You really have to convert tx16wx groups to splitted 1 sample groups, to use tx2sfz. That was the simplest way, to do it for me. But maybe in the long future I could change that. It was a bit tricky in the beginning, but maybe now I would have done it in another way.
Sounddigger wrote: > Another value that is (still) not correct by default, is the volume. I don't understand why setting it to "0" in the menu in the top bar doesn't set it at 0 but to -6.93 (in my case), nor why setting it at "+6" doesn't correct it to a final setting of 0dB.
That were peanuts to me so far. Tx16Wx has values from 0 to 1 & I had to translate them to dbs. Setting +6 db should be approximately 0, I thought. Don't take them too exact. Or is that necessary, to have them 100% correct... what is "correct"?
Sounddigger wrote: > Apparently, filter settings are VERY difficult to convert properly. And I found that from the samplers/synths I tested, only SFZ player and Sforzando import some filter setting, but only when coded meticulously.
I didn't implement filter readings in the upload so far. It works here quite well, I was impressed for myself how well translation did work! (BUt AGAIN: IT's NOT implemented in the uploaded version so far, just in my personal next generation version :-) !!!)

Sounddigger wrote: By the way, it would be handy to have this field as easy to use as a text editor like Notepad or Vim/gVim, with the possibility of direct text input, since the idea is to try out different settings.
It's at the end of my list :-). Makes sense.
Sounddigger wrote: > After working on a certain file, when loading a new TX16Wz file into tx2sfz, blue fields that contain codes copied from the yellow fields are NOT reset (to blank). Weird. Good reset operation needed.
That is in the nature of these fields... Although there is a possibility to really work with something like presets, which would include a reset... But I don't know how screwed tx2sfz is by now & how much work it would be to go into that direction...
Sounddigger wrote: > You mention (in the tx2sfz window) that before loading a TX16Wz file into tx2sfz, all "Groups" should be saved into "single sample groups". Is there a quick button for that in TX16Wz?
I explained wrongly: You have to do it in Tx16Wx. There is a feature for that!
Sounddigger wrote: It seems that separate "Groups" of the TX16Wz file end up in "Regions" in the converted output SFZ file. Weird... Even weirder, when loading some of these SFZ files with different regions back into TX16Wz, these get grouped into separate groups! I got this when converting a simple velocity-layered setting. Samples got grouped by their velocity range, not their key range. Duh...
So far tx2sfz works really only in one way: Do not set ANY groups in tx16wx. Split all groups to single sample groups. That way it worked perfectly for me so far.
Tx16wx uses splitpoints within groups to locate single samples. I could not follow these workflow as it is not my way to work. I didn't like it, but understand why it should be good.
I just wanted tx2sfz to be able to spit out a tx16wx program which would sound about the same in sforzando & following these straight restrictions that is absolutely possible for me.
Sounddigger wrote: > It would be useful to have an undo function for at least one past action, such as for incorrect paste or text input.
Not possible for me so far... BUT: I plan tx2sfz to be a vst in the end & so you should be able to use host undo... I don't know, but it could work...
Sounddigger wrote: > It would be useful to have a little help file (PDF?), in which some of the functions and menus are described. Be sure to include a description of all the menus of the top bar, and what settings to use. For example, what "root" settings should be used (and why/when)?
OF COURSE !!!!!! Sorry, for not having the time so far.
Sounddigger wrote: and that it will help to put together a nice update!
That's optimistic :-) Lets say: These alone will be 30 updates.


Martin[/quote]

Post

I just wanted to comment and say that this converter is a great idea, and I think it is a very needed application! Thanks! :-)

--Sean
C/R, dongles & other intrusive copy protection equals less-control & more-hassle for consumers. Company gone-can’t authorize. Limit to # of auths. Instability-ie PACE. Forced internet auths. THE HONEST ARE HASSLED, NOT THE PIRATES.

Post

Thanks! I'm too lazy to make another update, so the online-version is quite outdated, although good ressults for some purpose can be achieved!

I'm still adding value reads & have a lot of success with the internal logic which results in better readability of the output files. It also writes note numbers now... I think, when TX16Wx will be released, tx2sfz will be in a good shape to be uploaded & updated again.

Any idea what "Section#1:<region> cleaning opcode () failed" means in sforzando????

Post

ah, found it.

Post Reply

Return to “CWITEC”