saving/loading sample banks (as single file)

[KG_is_back]

I have several ideas how this could work.

Here's the main question can Ruby read data from specific address in RAM? If so, mems and memArrays may be serialized and saved as a single file (+ with various other data, for example preset strings). This would allow saving entire sample bank as a single file (something we wanted for ages).
If ruby can't do it, perhaps DLL can. Anyone tried this? Or has some insight?
Loading the file back to memArray may involve temporary files (perhaps also DLL to convert raw PCM to WAV, but not necesairly).

Other solution I have in mind is to iterate over the waveArray, save each wave as a temporary file and then add the content of the wav file into a single "sample bank" file. Loading the "sample bank" wound involve creating temporary file, copying each wav from the sample bank there one by one and loading them. This would avoid need to convert between PCM and WAV, thus might be possible without DLL.

[Jay]

I've been using this method for several years to store and load 1024 point wavetables, I have 2500 waveforms spread across 43 banks, each bank is a wave stored in a wave array, the wavetables are laid end to end in the wave file and i just use the float array section prim to retrieve a 1024 sample slice from the wave at a given index!

this works well for wavetables of a fixed size but i was never able to come up with a way of doing it with samples/waveforms of differing sizes, it would be interesting to see what could be done nowadays with all the extra ruby and dll goodies in flowstone

[Youlean]

I have never worked with files in dll, but I think that it can be done by using multi dimensional arrays, or even string array I think that there is not 255 character limitation per line in dll, so basically you could write every sample in different line and save it as text file. That's what comes to my mind right now...

[KG_is_back]

Here is a schematic with pseudo-code of how it should work. Hopefully it's clear enough.

[RJHollins]

I'm not sure if my following suggestion would be of any use or applicable to the project .... but ...

A while back, I needed to handle a group of variable sized arrays to be stored in a single file. Due to the nature of the data size [indexes], I would not know how many entries an array might contain. Managing these became a major concern, and resulted in a rather complex schematic design.

Then, Mr NUBEAT introduced me to a file management protocol called 'Marshall' [all done in RUBY]. From my understanding, it is a similar file management that SM/FS use natively.

I can tell you all the brilliance of this function. NuBeat even presented it in a way that even I could follow and understand. I have used this same concept in many of my projects and it has worked flawlessly, and has greatly simplified this aspect of programs needing this ability.

Don't have a link off hand ... can't recall, but it should be on the FS forum [because of RUBY].

Maybe this could be of help?

[KG_is_back]

Thanks for pointing that out, yes, I'm aware of the Marshall. From what I understand, it basically serializes data into binary string (which can be directly expressed as string of chars), allowing it to fit into a file. In this particular example, I (suspect) do not have to marshall the files themselves, because they are already serialized. All I need to Marshall is the sizes.

Or maybe you mean like putting the files into an array and marshall that array? also good...

[tulamide]

The current logic of the pseudo-code won't work. The SaveWave prim will create a .wav file. Since you always send the same path (incl. file name), you will end up having just one .wav (the last generated one).

Better have tempPath without a file name, instead in the loop call output 1 with @tempPath + "temp" + j.to_s
Now you have @size number of files named temp1, temp2, etc.
Concatenate them using the binary mode "b", for example:

Code: Select all

File.new(@path, "wb") do |result|
    (0...@size).each do |index|
        file = @tempPath + "temp" + index.to_s
        result.write(File.open(file, 'rb').read)
    end
end

Of course this is also just to show the right direction. There's a lot missing, like writing the number of files and such.

[KG_is_back]

My point was, to use a single "temp.wav" file. Kinda should go like this:

1.save mem as temp.wav
2.use ruby to extract data from temp.wav and put it at the end of "bank"file
3.save another mem to the same "temp.wav"
4.use ruby to extract data from temp.wav and put it at the end of "bank"file
...
???. delete the temp.wav

Concatenate them using the binary mode "b"

what does that mean? It's like appending them to a single file? Can they then be separated?

[tulamide]

My point was, to use a single "temp.wav" file. Kinda should go like this:

1.save mem as temp.wav
2.use ruby to extract data from temp.wav and put it at the end of "bank"file
3.save another mem to the same "temp.wav"
4.use ruby to extract data from temp.wav and put it at the end of "bank"file
...
???. delete the temp.wav

I see. A misunderstanding then. To extract the data you would need to write a wave file parser.

It's like appending them to a single file? Can they then be separated?

Yes and yes. For the second yes you would need to store the length of the file before the file itself. The when reading the "bank" you first read the length then the file, and so on.

[KG_is_back]

Yes and yes. For the second yes you would need to store the length of the file before the file itself. The when reading the "bank" you first read the length then the file, and so on.

that's kind of the part of my pseudocode. The length (preferably in bytes) is stored just before each wave file. The opening works kinda like this:
1.create empty temp.wav and set @i=0
1.form the "bank"file read the first 4 bytes as int (determines the size of the following data) ->size
2.copy bytes[5..(4+size)] to temp.wav
3.load the temp.wav to waveArray prim at first index
4.set @i=@i+4+size
5.form the "bank"file read the 4 bytes as int starting from @i ->size
6.copy bytes[@i+5..(@i+4+size)] to temp.wav
7.load the temp.wav to waveArray prim at respective index
8.repeat steps 4-7 until the end of the "bank"file
9.delete temp.wav

the bank would contain some additional info on the beginning, including no. of wave files. These will be separated before step 1. (so actually the first segment wouldn't go to temp.wav but a string output on the rubyedit module.

What concerns me is synchronization... Ruby and green work on different threads right? what might happen for example that ruby will execute step 6. before green manages to finish step 3. Best case scenario: Some wavefiles might end up missing and others will be doubled. Worse case scenario: Since copy of information is not allowed by quantum mechanics, as well as loss of information, the fabric of space-time continuum will rupture and two-headed-unicorn will pup into existence.