DSP Robotics Support

I wish so badly since years to have just a gui based editor for drag & drop wav files on the keys and setting zones. Of course velocity ranges & groups would be cool. I can't find a software to do that as easy as possible. Of course I would pay 100€ for a complex editor (I don't want to buy translator or constructor because of reading many bad things about them & I want to be able to use the software on different machines).

Could someone explain me the steps I would have to go through to create such thing with synthmaker/Flowstone...?

One should drag and drop samples on a virtual keyboard & edit their zone ranges + automatically setting root key to dropped on key + setting velocity ranges & maybe group settings. No further opcodes needed, which can be easily done with sfzed or manually. The program should save a textfile with sfz extension. Being able to Monitor the used samples would be cool.

I always read one should use a texteditor, but I don't understand how to do it faster than drag & drop samples on a keyboard!? I build samples very often and like to do it very fast...

When I start now, maybe I'm there in a year. I waited so long for a FAST & easy editor.

With best regards

Martin

Another idea would be to build a translator for files from the Tx16wx vsti samler which has a very nice gui & editing possibilities + a fully documented file format.
What steps are necessery for such thing?

Yes, that would be a really cool thing to have.
Just had a look at the SFZ file format, and it's structured to make this kind of parsing as easy as possible.

I think that dragging from the desktop/folders is the only thing that would present a major headache - the rest wouldn't be simple necessarily, but certainly possible.
It would definitely be an easier task in FlowStone than SM. The new Ruby programming is perfectly suited to many of the jobs that'll need doing as it has much better access to the file system, very powerful text parsing and string processing, and supports any kind of nested structures of data that you can imagine.
In principle it should not be so different from the vector graphics code generator that I've been working on - giving parameters a value from their graphical representation, and then stringing together the values and pre-defined tags with the right syntax.

Drag 'n' Drop from outside the application would need some sort of Windows support like OLE which we don't have yet - but a custom file browser within the 'plugin' window is something I've already been experimenting with. I'm way off a complete solution, but I can see that something pretty versatile is possible with a bit of work.
A browser within the software isn't necessarily a big disadvantage, either - it allow the chance to define your own ways of filtering and sorting files, and you could automate some of the file 'archiving' to put together nice foldered sfz definitions along with all their samples.

Using Ruby would make structuring the data within the application much simpler - you'll have several data items to each region, several regions in each file, and possibly several groups also containing regions. Green data is not easy to use for nested structures like that, and since this is 'keyed' data to begin with, hashes would probably be better than arrays anyway - things which Ruby is very adept at.
Id suggest that this is the place to start - defining the data structure, sticking some 'dummy' data into it, and then ensuring that you can produce a viable SFZ file from it. It's tempting to get stuck into the interface and all the pretty bits first, but that will be pretty complex, and probably the trickiest bit to edit later on if you find that the 'database' structure has to change. The data processing and file output is also the bit where you could re-use all of the same code in a batch-convertor or file translator later on, or if the GUI proved too difficult to implement.

I see, I'm far away from it, but this is a start now...
So when I want to learn something about programming it's not wrong to start with ruby inside flowstone? Or is that too complicated (when trying to find ideas on the web, I stumbled over visual basic several times..., would that be a better start?).

Maybe I'll try to find a way to realize the translator for the tx16wx programs into sfz...
So I need to read textfiles, look for specific expressions, extract some informations and put them back to another txt file with different extension...

I bet I can't get better than Tx16wx s gui anyway. Converting those programs should be the easiest and fastest way...

Well, a solution can certainly be had using FlowStone. I couldn't really comment whether VB or some other language might be better, as Ruby is really my first dabble for a very long time in these kind of languages; I've had my head stuck in DSP assembly for too long with SM!
If it's just a file translator that you want to make, then there will be dozens of languages capable of doing that. If you haven't already found a language that you're comfortable with, then I'd say that Ruby lives up to its reputation of being quick to learn and get results with - but whatever you choose, there'll be a forum much like this one with folks to help you find your feet.
If you're writing a text parser, you'll find that the looping structures etc. of most languages are fairly interchangeable, and the bulk of the work will be done by 'regular expressions', which are also commonplace. They're what you use to detect and retrieve sections of text that meet certain patterns, and are a bit cryptic sometimes, so worth getting a bit of practice with - for example...

...means "does this string end in a dash followed by two digits?"

FS would certainly come into its own if you wanted to go further than that and make an editor GUI, or have a live MIDI input for previewing the splits as you edited them - those are the parts where I think it would save a lot of work if you're not familiar with another programming language. And if you did choose FS and Ruby, a lot of what you learned would be very useful if you decided to learn other languages later - there's a lot of common ground between them.

File access things, I have no idea how others compare, but Ruby seems able to do anything that the OS file and folder permissions allow, and text files are very easy to handle. I imagine that most of the other options have similar abilities, but the Ruby books that I've read seem to have quite a few examples of how Ruby makes it easier to do than other languages.

There's a thread HERE that collects together some of the free Ruby guides and documents that forum users have found - Ruby is pretty new to us all here, so most of them are pitched at beginners; and if you don't have FS, you can still use the demo to open a Ruby editor and have a tinker to see if you like it.

I may be able to give you some idea of the work involved fairly soon. I'm wanting to do essentially the same thing as you, only with SVG files, as part of my graphics editor - to give a way of treating FS vector graphics as files, just as we do with bitmaps.
There will certainly be some useful lessons come out of that, and maybe even a few bits of code that could be shared, as the SVG format is a very similar kind of tagged text file.

Since years I say I want to learn programming, so now seems to be the time to do the first step. I have bought FS, so you motivated me in starting with ruby. I have really no idea, how far this will take me, or if I'm able to learn that at all while being a really motivated father of a 2 1/2 year old daughter and with a teacher job... I will try to find a basic understanding for ruby first, but this may take some time.

Thanks for your big help!

You''re welcome, and welcome to the club.

As you sound like you have a lot to juggle, here's a couple of observations from my own time starting out that might help save you a blind alley or two...

- There's no real Ruby training in the FS manuals, it only really covers the "special features" that DSPr have added. But the guides etc. in the list before, while many are very good, don't take into account that we're using Ruby in a slightly 'alien' environment. Which can cause a little confusion at times, and also means that the "syllabus" might need a bit of tweaking for our special requirements.

Firstly, the immediate confuson...

Most early example programs you'll see assume that you are typing data into a text window acting as a 'terminal', and that Ruby will print its output to the same window. By default, the commands for this are "puts" ('puts' something on screen) and "gets" ('gets' some user input) - and you'll see a lot of them to start with.
This won't work for an FS Ruby editor, as it is communicating with the rest of your schematic, not a text 'terminal'.

For many of these examples, we can make an FS substitute - first grab a couple of Text boxes from the toolbox and connect one to the input and one to the output of the Ruby primitive.
Now, wherever you see "puts XXXXXXX" in the code, replace it with "output XXXXXXX" - and you'll have a display for the results of the program.
Input is a little more tricky, and you won't always be able to emulate "gets" quite so easily. But usually the input value is assigned to a variable...
myAnswer = gets()
Replace this with
myAnswer = @in
And it will take the value from whatever you type into the "input" text box.

The Ruby inputs and outputs part of the FS manual is worth getting to grips with early on, as it is really the only major departure from the standard Ruby language - everything else FS-wise is "added features" and can be learned later.

Also the command "watch" is very useful - this uses the readout at the bottom of the Ruby window to let you peek at the any value within the code at any point. Being able to see the result of intermediate steps in the program is a very powerful tool, for learning and de-bugging!

Syllabus

You'll see that most resources spend a lot of time dealing with building new classes of objects - it's an object-oriented language, so that's to be expected.
You do need to understand what a class is - and likewise objects and methods - they are all fundamental. But I would advise not getting bogged down in how you create new classes, modules, mixins etc.
They are very powerful features, and crucial to stand-alone Ruby programming; but in the context of FS seem not quite so important due to all the other tools at our disposal in the toolbox. They are also things that require a little extra care than usual due to the way Ruby is set up to be embedded within FS.

For the kind of features something like the sample translator needs, it would be better to concentrate on the different classes of data, using collections of objects, and manipulating text and numbers. The art of programming really is in being clear in your mind what is happening to your data at all times - and that is far easier learned from "longhand" code using the simplest commands that make every operation explicit. Ruby is pretty tough to make crash, so just shove everything you can think of through each new command until you can predict just what the result will be every time - including the ones that will generate an error, as the books often don't give many negative examples. Get those clear in your mind, and you'll find that many of the more advanced commands become self-explanatory, and making more compact and efficient code will fall into place easily.

I hope you enjoy the journey, but for the sake of your partner and daughter, please try not to become quite as obsessed with it as I have!

O.K. I just read two dozends of simple examples in ruby & have the feeling, that it at least should be possible for me, to code a converter from TX16WX freeware software to SFZ format in ruby code. Getting it working inside Flowstone
and making it GUIbased with own editing possibilities is far away, but a simple converter should be possible for me.

Writing a txt file shouldn't be a problem.
I just have to let ruby identify the relevant parameters and make it react writing the sfz format in a new txt (sfz) file. I have to tell ruby to get that "OberflächeA.wav" and write it in a txt file after "sample="; get information for the id"1" sample hikey= & lokey= (found after tx:range tx:lowkey) and velocity settings. Then the same for sample id"2" ...

For now I just look for methods that fit my needs & try to understand the logic behind them. That will take some time for me.

Here is the code of a (nonsense) TX16WX - program:

<?xml version="1.0" encoding="utf-16"?>
<tx:program
xmlns:tx="http://www.tx16wx.com/2.0/program"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.tx16wx.com/2.0/program txprogram.xsd"
tx:created-by="2002"
tx:name="tx16test"
>
<tx:wave tx:id="1" tx:path="OberflächeA render 001.wav"/>
<tx:wave tx:id="2" tx:path="OberflächeA render 002.wav"/>
<tx:wave tx:id="3" tx:path="OberflächeA render 003.wav"/>
<tx:wave tx:id="4" tx:path="OberflächeA render 004.wav"/>
<tx:range tx:lowkey="C-1" tx:highkey="G9" tx:lowvel="0" tx:highvel="127"/>
<tx:group tx:name="OberflächeA render 001"
tx:coarse="0"
tx:fine="0"
tx:tuning="Fixed"
tx:glide="0.0ms"
tx:velocity="1.00"
tx:velocityOffset="0"
tx:pan="0.00"
tx:amp="0.50"
tx:playmode="Normal"
tx:polymode="Poly"
tx:output="(ch)"
tx:start="0.0ms"
tx:chokeGroup="0"
>
<tx:range tx:lowkey="C1" tx:highkey="C2" tx:lowvel="28" tx:highvel="76"/>
<tx:aeg tx:attack="0.0ms" tx:decay1="0.0ms" tx:level1="1.00" tx:decay2="0.0ms" tx:sustain="1.00" tx:release="0.0ms"/>
<tx:env1 tx:level0="0.00" tx:time1="1.00s" tx:level1="0.00" tx:time2="1.00s" tx:level2="0.00" tx:time3="1.00s" tx:level3="0.00" tx:amp="1"/>
<tx:env2 tx:level0="0.00" tx:time1="1.00s" tx:level1="0.00" tx:time2="1.00s" tx:level2="0.00" tx:time3="1.00s" tx:level3="0.00" tx:amp="1"/>
<tx:lfo1 tx:rate="0.50 Hz" tx:type="Sinus" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00"/>
<tx:lfo2 tx:rate="0.50 Hz" tx:type="Sinus" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00"/>
<tx:seq1 tx:rate="0.50 Hz" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00" tx:length="0" tx:smooth="0" tx:stepsync="0" />
<tx:seq2 tx:rate="0.50 Hz" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00" tx:length="0" tx:smooth="0" tx:stepsync="0" />
<tx:seq3 tx:rate="0.50 Hz" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00" tx:length="0" tx:smooth="0" tx:stepsync="0" />
<tx:filter tx:type="Off" tx:freq="20000 Hz" tx:res="0.00" tx:drive="0.00"/>
<tx:modulation>
</tx:modulation>
<tx:split tx:wave="1" tx:key="C1" tx:loop="-1" tx:release="-1"/>
</tx:group>
<tx:group tx:name="OberflächeA render 002"
tx:coarse="0"
tx:fine="0"
tx:tuning="Fixed"
tx:glide="0.0ms"
tx:velocity="1.00"
tx:velocityOffset="0"
tx:pan="0.00"
tx:amp="0.50"
tx:playmode="Normal"
tx:polymode="Poly"
tx:output="(ch)"
tx:start="0.0ms"
tx:chokeGroup="0"
>
<tx:range tx:lowkey="C#2" tx:highkey="D2" tx:lowvel="28" tx:highvel="76"/>
<tx:aeg tx:attack="0.0ms" tx:decay1="0.0ms" tx:level1="1.00" tx:decay2="0.0ms" tx:sustain="1.00" tx:release="0.0ms"/>
<tx:env1 tx:level0="0.00" tx:time1="1.00s" tx:level1="0.00" tx:time2="1.00s" tx:level2="0.00" tx:time3="1.00s" tx:level3="0.00" tx:amp="1"/>
<tx:env2 tx:level0="0.00" tx:time1="1.00s" tx:level1="0.00" tx:time2="1.00s" tx:level2="0.00" tx:time3="1.00s" tx:level3="0.00" tx:amp="1"/>
<tx:lfo1 tx:rate="0.50 Hz" tx:type="Sinus" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00"/>
<tx:lfo2 tx:rate="0.50 Hz" tx:type="Sinus" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00"/>
<tx:seq1 tx:rate="0.50 Hz" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00" tx:length="0" tx:smooth="0" tx:stepsync="0" />
<tx:seq2 tx:rate="0.50 Hz" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00" tx:length="0" tx:smooth="0" tx:stepsync="0" />
<tx:seq3 tx:rate="0.50 Hz" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00" tx:length="0" tx:smooth="0" tx:stepsync="0" />
<tx:filter tx:type="Off" tx:freq="20000 Hz" tx:res="0.00" tx:drive="0.00"/>
<tx:modulation>
</tx:modulation>
<tx:split tx:wave="2" tx:key="C#2" tx:loop="-1" tx:release="-1"/>
</tx:group>
<tx:group tx:name="OberflächeA render 003"
tx:coarse="0"
tx:fine="0"
tx:tuning="Fixed"
tx:glide="0.0ms"
tx:velocity="1.00"
tx:velocityOffset="0"
tx:pan="0.00"
tx:amp="0.50"
tx:playmode="Normal"
tx:polymode="Poly"
tx:output="(ch)"
tx:start="0.0ms"
tx:chokeGroup="0"
>
<tx:range tx:lowkey="D#2" tx:highkey="E2" tx:lowvel="28" tx:highvel="76"/>
<tx:aeg tx:attack="0.0ms" tx:decay1="0.0ms" tx:level1="1.00" tx:decay2="0.0ms" tx:sustain="1.00" tx:release="0.0ms"/>
<tx:env1 tx:level0="0.00" tx:time1="1.00s" tx:level1="0.00" tx:time2="1.00s" tx:level2="0.00" tx:time3="1.00s" tx:level3="0.00" tx:amp="1"/>
<tx:env2 tx:level0="0.00" tx:time1="1.00s" tx:level1="0.00" tx:time2="1.00s" tx:level2="0.00" tx:time3="1.00s" tx:level3="0.00" tx:amp="1"/>
<tx:lfo1 tx:rate="0.50 Hz" tx:type="Sinus" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00"/>
<tx:lfo2 tx:rate="0.50 Hz" tx:type="Sinus" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00"/>
<tx:seq1 tx:rate="0.50 Hz" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00" tx:length="0" tx:smooth="0" tx:stepsync="0" />
<tx:seq2 tx:rate="0.50 Hz" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00" tx:length="0" tx:smooth="0" tx:stepsync="0" />
<tx:seq3 tx:rate="0.50 Hz" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00" tx:length="0" tx:smooth="0" tx:stepsync="0" />
<tx:filter tx:type="Off" tx:freq="20000 Hz" tx:res="0.00" tx:drive="0.00"/>
<tx:modulation>
</tx:modulation>
<tx:split tx:wave="3" tx:key="D#2" tx:loop="-1" tx:release="-1"/>
</tx:group>
<tx:group tx:name="OberflächeA render 004"
tx:coarse="0"
tx:fine="0"
tx:tuning="Fixed"
tx:glide="0.0ms"
tx:velocity="1.00"
tx:velocityOffset="0"
tx:pan="0.00"
tx:amp="0.50"
tx:playmode="Normal"
tx:polymode="Poly"
tx:output="(ch)"
tx:start="0.0ms"
tx:chokeGroup="0"
>
<tx:range tx:lowkey="F2" tx:highkey="C4" tx:lowvel="28" tx:highvel="76"/>
<tx:aeg tx:attack="0.0ms" tx:decay1="0.0ms" tx:level1="1.00" tx:decay2="0.0ms" tx:sustain="1.00" tx:release="0.0ms"/>
<tx:env1 tx:level0="0.00" tx:time1="1.00s" tx:level1="0.00" tx:time2="1.00s" tx:level2="0.00" tx:time3="1.00s" tx:level3="0.00" tx:amp="1"/>
<tx:env2 tx:level0="0.00" tx:time1="1.00s" tx:level1="0.00" tx:time2="1.00s" tx:level2="0.00" tx:time3="1.00s" tx:level3="0.00" tx:amp="1"/>
<tx:lfo1 tx:rate="0.50 Hz" tx:type="Sinus" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00"/>
<tx:lfo2 tx:rate="0.50 Hz" tx:type="Sinus" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00"/>
<tx:seq1 tx:rate="0.50 Hz" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00" tx:length="0" tx:smooth="0" tx:stepsync="0" />
<tx:seq2 tx:rate="0.50 Hz" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00" tx:length="0" tx:smooth="0" tx:stepsync="0" />
<tx:seq3 tx:rate="0.50 Hz" tx:sync="None" tx:trig="Retrig" tx:fadein="0.0ms" tx:pos="0.00" tx:amp="1.00" tx:length="0" tx:smooth="0" tx:stepsync="0" />
<tx:filter tx:type="Off" tx:freq="20000 Hz" tx:res="0.00" tx:drive="0.00"/>
<tx:modulation>
</tx:modulation>
<tx:split tx:wave="4" tx:key="F2" tx:loop="-1" tx:release="-1"/>
</tx:group>
</tx:program>

Seeing that TX file makes me even more confident that FS/Ruby can get this working - the similarities with the SFZ format just shine out.
Of course, there may be a few keys without direct equivalents, but the general structure is obviously designed to make it easily readable - the developers could so easily have chosen to hide everything in a custom binary format, so it is very pleasing to see just how legible it is.

The way you described the problem leaves me in no doubt that you'll succeed with a little perseverance learning Ruby - you have broken the problem down into simple steps in just the same way that any programmer with years of experience would have done, and with perfect precision.
In my experience, folks who really struggle with programming do so because they find it hard to describe the problem to themselves, rather than any difficulty turning an exact expression of the problem into valid syntax.

Aahhh, I see... Now I work inside flowstone.

Simple (I guess) question how can I drag and drop a sample & get it's location as string. Or how are such things done ?