Hi All,
What is the best way to load a .wav file into a table without [soundfiler].
I can record audio and play it back but am stuck on how load a sample into the Daisy’s Seed ram?
Thanks again,
/S
1 Like
What you can do is first load the file into a table (I usually use [readsf~] object for this), and then make sure to save the table with the patch.
Right click on the table object and mark the Save contents checkbox.
After this remove readsf~ or soundfiler object again so that you can compile the patch.
You will most likely need to build/flash with size optimizations enabled, otherwise the patch won’t fit in the program memory.
2 Likes
@dreamer I had the same objective here a few weeks ago and tried with the Save contents flag after right clicking the graph behind the table object. Unfortunately, the data doesn’t seem to be saved though - it’s not written in the pd file. (would be happy to see that I’m wrong about this - but don’t know how to achieve it!)
In the end, my solution was quite ugly … I sent a series of indexes and values via [<index> <value>, <index> <value>, ...( → [s <table_name>] to the table to fill it with data (the array message syntax with start index and value series didn’t work for me neither). But that’s obivously not very convenient for a larger wave file.
Do you mean that if you re-open the pd file that your sample is not in the table? Then you must be doing something wrong. When I do this here I can always open the pd file and the contents are stored.
(btw I have yet to do this sample loading on the Daisy specifically. I just know that this does work with HVCC for desktop plugins and such)
Oh, I thought [readsf~] wasn’t supported by hvcc compiler for seed (I guess this is continually evolving). I will go back and try again.
Am I right in saying, when the save content flag is used, the table data is saved in the PD patch itself, which, when compiled for the seed, is transferred across into the ram of the seed? (apologies if this is really obvious). ben-we, dreamer Thanks again /S
dreamer, apologies, I miss read your post. Now see how you are using [readsf~].
/S
hmm … would be great to know what exactly I’m doing wrong here then.
I only get the Save contents option in the graph array properties (the dialog on the left is the properties of the table wav 131 object):
But when I save this after confirming the dialogs, this is the whole pd file content:
#N canvas 275 210 672 530 12;
#X obj 65 139 tabosc4~ wav;
#X obj 65 114 sig~ 120;
#X obj 65 49 table wav 131;
#X obj 65 163 dac~ 1;
#X connect 0 0 3 0;
#X connect 1 0 0 0;
@dreamer let me know what you’re doing differently here to get the data saved.
readsf~ and soundfiler are indeed not supported. You have to remove them after you are done using them.
I now managed to load a very small sample into a patch and I can only get a functional program if I turn all size optimizations off.
When I turn the size optimized linker on then the program is completely broken.
This is unfortunate as our program memory will get full very quickly without the size optimization.
I hope the team can come with a solution for this as loading samples would certainly be a lot of fun!
1 Like
ok this is a bit unintuitive, but the way to do this is to first create an array (ctrl+shift+a) which puts the graph directly in your patch. Then fill it with your desired data and save the contents.
I actually don’t know why it only works like this. You can also create a table and copy the graph out of it onto the parent patch and it will also work.
It would be nice if it worked exactly the same for table objects, but unfortunately it doesn’t (right now).
1 Like
oh … that’s not at all what i would have expected to work! 
thank you very much. i thought that the table object was actually needed here. i couldn’t put it on the daisy yet here now, but i see that it compiles. nice!
1 Like
Yeah it’s a bit confusing I agree. A canvas-graph is not the same as the [array] object. The later we don’t support, and the former I’m not sure how to call in the supported list 
The way I actually have been testing this is using the tabplay~ help (latest HVCC has tabplay~ supported) and I just copied that graph into other patches.
Actually I made a mistake with how I was (manually) flashing the bootloader, I can actually flash the patch with samples to the extended memory!
I managed to flash this “generative” drum machine onto the daisy extended memory:
However it seems that the table data gets flashed onto DTCMRAM which is very tight:
Memory region Used Size Region Size %age Used
FLASH: 0 GB 128 KB 0.00%
DTCMRAM: 129552 B 128 KB 98.84%
SRAM: 241304 B 512 KB 46.03%
RAM_D2_DMA: 16648 B 32 KB 50.81%
RAM_D2: 23428 B 256 KB 8.94%
RAM_D3: 0 GB 64 KB 0.00%
ITCMRAM: 0 GB 64 KB 0.00%
SDRAM: 0 GB 64 MB 0.00%
QSPIFLASH: 0 GB 7936 KB 0.00%
(and yes I’m using tabplay~ here because I’m testing latest HVCC changes. if you don’t know how to manually build and flash you will have to wait for the update to come to the plugdata toolchain)
3 Likes
I’ve also been able to flash a bit bigger program to QSPIFLASH, this gives us a lot more storage but I don’t know to what extend this will impact performance. Would need more testing.
Eventually I do see the possibility to develop a custom linker script so we can place specific parts of the code in different optimized regions of memory.
3 Likes