i was wondering if someone could help me out on why this looper will not work when flashed on my Patch_sm?
i made the patch on Plug Data and it tested it out on the program and it works as it should . But when i compile it and flash it onto the Patch_sm i hear no sound.
I know the inputs and outputs of the module work as i was able to just make a simple patch of [adc~] - [*~ 1] - [dac~]
any help would be great.
There are two ways to use the gate input, either as continuous 0 or 1 numbers, or as a boolean/bang output.
In the configuration that you are using it Gate1 it will continuously output 0 or 1 values.
If you want to have individual bang messages you will need to use the name Gate1_trig, which should flip the toggle in your patch any time you send a new gate signal into it.
I changed the Gate input to Gate1_trig but
im still not getting audio to even be read into the daisy.
The patch works in plug data when i click on the toggle and talk into the computer mic.
But when i flash the patch into Daisy . No audio is being detected.
I understand, but this is never a guarantee that it works with the compiled version. We are not running Pd on the Daisy!
Also you will need to flash with bootloader and use a custom linker as your desired size is very big. Are you doing this?
We’ve also seen some issues with using the [table] object, maybe try using the graphical array instead:
Thanks for all the help Dreamer.
When flashing on Plug Data i was selecting “Huge” for the Patch size.
I did not use a custom linker as i did not create one. I will have to look into making them.
I will give the Array a try in the patch.
You don’t have to create the linker, this is very non-trivial!
I think the main issue this is that your table is dynamically allocated and it won’t fit in the regular program memory. Therefore your Daisy will start and then likely immediately crash.
You can use the .lds files in the pd2dsy repository: https://github.com/electro-smith/pd2dsy/tree/master/util
The sdram versions are required for large dynamic tables. You will also need to select the SRAM or QSPI type.
(we will look at re-adding them, as using such dynamic tables for delays and such are very common)
[edit: hmm, I’m actually now thinking that this table is not dynamic at all and it will simply not fit the program … what is the size of the program in the table as it shows up in the plugdata compile window after building?]
Ok so i had some good results . i was able to get audio running in and out the Patch_sm.
I flashed it using the Huge size.
I used the Array object and lowered the size down to 48000.
I will need to look into a way i can get more sample time in.
But in the meantime im happy i got this patch making some sound
I just tested this using your patch and the graphical array, and using the Huge/QSPI flash I was able to put at least your 144000 size on there.
And if you use a custom linker that uses SDRAM you can go much further beyond this.
So what I said earlier about dynamic allocation is actually correct (should’ve double/triple checked before answering, but I didn’t have a Daisy on hand at the time)
I will investigate the issue with [table] object soon though (already have a ticket for it, just not had the chance to investigate).
[edit: oops, I mistyped. I was using 114000 as the size /o]
Little by late to the party I guess 
but I got the same problem with exactly the same patch with a Patch.init() module. I’m also using the graphical array and Huge/QSPI flash but when I send a trigger to the gate2 input (tried both Gate2 and Gate2_trig) I get no sound. The module is working fine with other patches and I’m using a gate output connected to an LED just for a graphical response of the patch; the led lights up when receiving the Gate2/gate2_trig pulse.
Do you know what I’m doing wrong? I’m quite a noob with PlugData, how can I change the array size?
Thanks a lot!
Just click on the array and edit the size in the sidebar:
Thank you, I’ve read your suggestions. I’m joining the thread since I’m trying too to make a simple looper using the Daisy Seed with a Pure Data patch, and I experience similar issues with array dimensions.
When I select “Huge” in the Plug Data compiler, everything works fine, as long as I put in my patch an array of size under 60000 or so. Beyond that value, I get no sound - but I just can’t understand exactly what happens, since QSPI memory usage is still under 5%.
If bigger sample sizes require the linker files you mentioned above, I would not know how to select them from the Plugdata compiler. Should I use the pd2dsy method?
Thanks!
In the latest nightly builds you can also directly select variations using SDRAM.
These dynamic tables do not show in the flash size, since that only includes the compiled program.
The dynamic tables are allocated dynamically (hence the name) when the device boots.
Using the SDRAM flash options the 64M SDRAM is used for this, which allows for larger tables for loopers, delays, reverbs, etc.
Thanks a lot!
I downloaded the latest nightly build and found the other compiling options.
With the “Big + SDRAM” option I can go up now to 120000 array points in the patch, then the compiler stops due to SRAM overflow. This is 2,5 seconds of sound, so this seems the max limit for embedding an array directly into the patch.
Since I’m interested in looping and granular synthesis, and I’d like to store longer/multiple samples to work with, what would be an object in Plugdata that allows to record a sample in the SDRAM using dynamic tables (aside from delwrite~/delread~, since a circular buffer would not work in my case)? Maybe it’s a naive question - I don’t know if I’ve completely understood your answer.
Yeah sorry I was a bit quick in answering this morning.
The fixed size table is not dynamic and will be stored in SRAM (Big) or QSPI (Huge), but dynamic tables are used with delwrite~/delread4~ and those will go into SDRAM.
So the only way to have a larger buffer is to use delwrite~ object to make it dynamically sized.
This is not the behavior that you want, so you can try QSPI which will be bigger, but might have some performance issues (since it is slower).
Ok, thanks ! Just some more questions:
why is it that the Huge (QSPI) option overflows SRAM way before filling up QSPI? At 8 % QSPI the SRAM is already in overflow (see image attached).
for storing large, static chunks of sound in SDRAM should I switch to C++ coding? (That should give me also the possibility to read soundfiles from SD card - which is not accessible from Heavy-compiled patches, I guess)
If that is the case, what would be some good starting points in the C++ examples (for Seed) for recording / reading soundfiles, and where exactly the information has to be put about GPIO config? It’s all in the main cpp file? I mean, for Plugdata you have to provide it in a separate (.json) file, this is no longer true for C++ code.. or not? And: if I wanted to copy some GPIO config for the SD card, for example, is there some file for Pod or Patch where I can steal from?
Thanks again!
The memory layout and how it works is quite a mystery to me, so I honestly can’t answer this truthfully.
For any C++ questions I recommend that you search, or open a new topic, on the forum.
Thank you for the suggestions; in the end I found a lot of valuable information - on Discord, in the Daisy online documentation and online (various projects on Github). I could write a first C++ code to record and playback samples to and fro SDRAM.
