While playing around with samples, tables and the play pitch object, I found this strange behavior
In this patch, if ever I make the size of the table bigger than 65536, the patching software disconnects. The patch actually works (you can play around with the knobs via gpio or midi cc) but it's in standalone mode.
granny1.axp (3.4 KB)
link to the raw audio file - mega
Any ideas ?
Try not using the Sdram load object. I have had a lot of issues with that object and dont use it. When using smaller sizes(for example for one cycle wavetables) there is no problem. But for bigger sample I have issues too. I use this setup instead. It takes a few more objects but it works most of the time and rarely disconnects.
Yes, I did notice that this was a work-around (while testing all combinations). Is there any way to have a trig to be sent on startup (or after n seconds)?
I think if the toggle is on when you make the patch live, the sample should play right away? I know, sometimes it doesnt, but most of the times it does... or else you can just off/on the toggle.
at a guess, its probably taking too long for the sample to load (with the other startup activity involved) and so the watchdog thread is killing the connection back to the computer.
Id have thought it would have used a separate thread and/or load the data in chunks to reduce the load.
what I use for bang on startup is a change object, it defaults to 0, so put a constant of 1 to its inlet, it will fire when the first control rate loop is run. you could vary this approach to introduce a delay if you wish.
What happens is during patch initialization, the communication with the GUI stalls, the GUI does not get acknowledgement for the ping packets it sends, and decides to hang up the communication.
Will do a quick fix...
@jaffasplaffa the "table/alloc 16b sdram" object was broken in release 1.0.5 and fixed in 1.0.6.
I increased the time allowed for a patch to initialize to 10 seconds, fix is in git, and will be in the next release.
Will do soon then