wave file to frame (RUBY)

[KG_is_back]

Hello guys...
A little project I started this evening. You can load Wave file and it can be converted to a ruby frame (+read all data like length, sample rate ,no.of channels etc.).
I'd like to make custom waveArray module with new waveArrayRead modules. Some of you guys have been working on this kind of stuff (using ruby frames for custom wavetable oscillators), so maybe you can help expanding this.

Currently it can read 8bit 16bit 32bit int files and 32bit float files. A-law and mu-law 8bit are not implemented yet.

UPDATE: loading in background now works

[tulamide]

I don't know if "wtf" is really the best abbreviation for this fine schematic, but I'm impressed, how fast you are. That was the result of just this evening? I wish I could work that fast. Good job so far. (You should clear the path, as one can read a user name in there. The path isn't valid anywhere else then on your pc anyway, so a clean file loader might be better)

For outputting a float array it might be better to use floatarray = frame.to_array and then select the range to output via floatarray[x..y]

That's all for today, had just a quick look. But this is really interesting!

[KG_is_back]

I don't know if "wtf" is really the best abbreviation for this fine schematic, but I'm impressed, how fast you are. That was the result of just this evening? I wish I could work that fast. Good job so far.

"Wave to Frame" I had a little thought about it yesterday and had a quick look at the wave file specification. Then it was a matter of following the specification to extract the data correctly. Surprisingly it was pretty straightforward and even the first prototype was working straight-away.

There is a problem I experienced. When wave file is too big, the rubyEdit freezes because of extensive processing. Loading the file as a whole (string) and then converting it to a frame is a way I abandoned straight away. Instead, I read the file via small buffers and convert and copy them to the pre-build empty frame.
I experimented with Thread class a little bit, to allow loading the frame in background, but with no luck. Do you have any experience with using threads?

[tulamide]

There is a problem I experienced. When wave file is too big, the rubyEdit freezes because of extensive processing. Loading the file as a whole (string) and then converting it to a frame is a way I abandoned straight away. Instead, I read the file via small buffers and convert and copy them to the pre-build empty frame.
I experimented with Thread class a little bit, to allow loading the frame in background, but with no luck. Do you have any experience with using threads?

There is no advantage in loading as a whole in a thread. In fact, most everyone will load in chunks like you do, else not just Ruby in Flowstone, but every language would freeze the ui while loading megabytes of data. A thread takes as much cpu as needed, just like the main thread (the one, Ruby runs in). From the description of method 'pass': "Give the thread scheduler a hint to pass execution to another thread. A running thread may or may not switch, it depends on OS and processor."

EDIT: Currently, an opened file isn't closed after read in (which locks it from use by other processes). In the wavefile class, add
@file.close
right before
return frame
in method loadFrame

[KG_is_back]

Just an idea... inside the loadFrame method, I'd put the loop that loads buffers into a new thread and give "pass" command on end of each iteration.
The effect I want to achieve: when you run loadFrame method, I want it to return (potentially) empty frame, which is slowly filled in the background if CPU is not busy, leaving enough CPU for main processes to run (thus not freezing the full thing). Perhaps I can even put "loadingProgress" variable, which the loadFrame will update on every iteration and that will be readable using "loadingProgress" method for example... I will try it straightaway...

[tulamide]

That's not so easy as you think. Here a few details to consider:

- A thread is passed the code to execute. Create a method and pass that method to the thread: mythread = Thread.new {myMethod(whateverparameters)}

- Don't call Thread.join

- A thread, when finished has a return value. This value is the last expression of the method you pass. So probably don't use the frame as return value. Rather make a RubyEdit class variable that the thread can use to fill with data.

-You don't need .pass, because a thread starts immediatly after creation, if resources are available.

- If you use more than one thread to read in the data chunks, you might need the mutex class to synchronize.

- Create a main loop (via timed event calling) to check the progress.

[KG_is_back]

Done... it sort of works... The loading ix extremely slow (like 5seconds of audio is loaded in 1 second).
Also there is a problem. Some files are not converted to frames properly and I fail to find out why...

(schematic in the first post, also with a wave player)

[Jay]

It plays back at about quarter speed on my machine, like a slowed down record, is it supposed to work like that?

[tulamide]

It's half speed on my pc, but no matter if quarter or half, the sample rate seems to be interpreted wrong. Also, you still don't properly close the file after reading. With the new threading you now want to close the file as soon as progress is 100%.

The thread is not properly terminated on exit (for, example, when exiting Flowstone, or closing the schematic while the thread is still active), leading to Flowstone crashing. Thread.kill(thread variable) will do the job.

It is slow progressing because it is in another thread now. The main thread is Ruby, the sub thread is loading. Maybe the use of several threads that work on different parts of the data could speed it up. Say you read in the data in blocks of 1024 bytes (256 x 4-byte-values). You could create, say, 4 threads.

Thread 1 will load 0-1023, 4096-5119, etc.
Thread 2 1024-2047, 5120-6143, etc
Thread 3 2048-3071, 6144-7167, etc.
Thread 4 3072-4095, 7168-8191, etc.

Each thread offsetted by 1024 bytes from the prior one and stepping 4096 bytes. Of course, this needs to be adapted for the number of threads you use.

But that's no guarantee it will be faster, because, I learnt that from some one here on the forums, even on multicore cpus, multi-threading != multi-processing.

[KG_is_back]

It plays back at about quarter speed on my machine, like a slowed down record, is it supposed to work like that?

The playback was just for testing purposes - it reads the file as mono. If you load stereo file, it will read it at half speed (because of how left and right samples are serialized).

I think I need to optimize the loading mechanism to increase the speed. However, I do not know how... currently it reads a buffer form the file, converts it to float/int array via "unpack" method, converts to float array (if necessary = for int formats) and finally writes the array sample by sample to the frame.