using latest Beta Version Firmware v2.0.0-dev-13.7 +plugs, the options menu is not accessible after loadin- playing this patch (system set to 48/128, plugins loaded: biddo, fund, mshack, bog):
im using 12x 43.5 second 48k/16bit wav files all filled with brown noise. i can post a wetransfer link if that would help
im noticing that the issue happens in some instance of canard in this patch, but not in other instances of canard. it feels random. so you might have to try accessing it in several instances of canard before running into it.
OK, you might need to share the samples. Or more detailed step-by-step to make it happen. Here’s what I did:
Power on (no plugins auto-loaded, no startup patch)
Set to 48k/128
Load the four plugins you mention
Open the patch file
Insert USB disk which contains sounds/set01/stem*.wav
Press play
Turn up all knobs (making sure catchup mode catches them)
Navigate to the first canard, and click it.
Scroll down and verify it says “Options>>”
Hit Back
Repeat previous three steps, picking the next canard in the patch each time.
I’ve been through them twice (actually four times, because the first time I tried I was at 24k by accident). Every module has the menu. Do I need to click the Options menu? Maybe I need to do something else (adjust some knobs, press pause/play, attach MIDI, reload patch via Wifi, leave patch and come back, go to Knob Set view, click on something/anything?)
So, I’m not seeing the options menu gone using your samples, either. I tried opening each canard twice, and the menu was there on each one.
I’m literally just clicking on a canard, scrolling the bottom and visually seeing that the word Options with a >>> under it is there. Then I hit Back and go to the next canard. All knobs are up and I hear the noise.
I’m not clicking on Options. Should I be?
Maybe I’m not understanding what I’m supposed to look for. You’re saying that the word “options” is sometimes not present at the bottom of the list of the knobs and jacks, right? Or are you saying something else?
Can you be more specific about exact steps I would need to do in order to see this happen? You can use my step-by-step as a template, and add in any extra clicks or external signals or anything else you do that’s different.
High ram usage shouldn’t make the menu not appear. Maybe if it were at 99%, since the menu needs some RAM, but not at 205/290mb.
sorry i wasn’t fully clear previously; way too much going on these days! so the options button is there, but the problem is, when clicking on it to drill down to get to the actually options like “load sample”… thats not working. i just keep clicking on thst options button, but am not taken to inside the option menu to acces the actual options.
im away from the studio atm but will get those exact repro steps and a video for you asap
OK, thanks! That’s very clear now. I think I saw that happen when I was playing around but the whole UI is sluggish with the number of screens so I thought I just didn’t hold the button long enough. But I see now, it’s something else.
The button and menu are actually “working”… it’s just that the rendering is taking so long that you have to hold the button down for a while to get the MM to recognize the click. But — if you hold it down too long, then the GUI sees a “long press” event which does nothing. So, it’s randomly sometimes very difficult to get the menu to open.
I looked the Bidoo code to see why rendering was so slow. The draw function for the Canard was copying the entire sample buffer to a temporary buffer just for the purpose of drawing the waveform. I took that out and have it just draw the waveform from the actual waveform (no need to copy a 8MB file every single frame). Rendering time went from 500ms (ie. 2FPS) to 70ms (i.e. 14FPS)
This extra memory usage might explain some of the behaviors reported where the module uses more memory than expected
Hmm…
There’s another thing, the Async run_once gets called repeatedly (50+ times) for short samples. I’m not sure how that plays out with the lock(), it’s clearly not loading from disk 50 times, but it’s probably not good to have this. I’ll put in a check for the lock before calling the run_once.
There are some concurrency issues in the Canard, too. I’m trying to make sense of it – the lock() can’t appear in the audio thread (that will freeze the audio thread if the GUI thread locks it, but only if the module is running on the same core as the GUI, which is 50% of the time). Maybe the purpose of the big copy for the rendering was to avoid some of these issues, but even with the copy present, it could make the audio thread freeze (consider if a trigger into Clear was fired while the gui was copying the sample data – we would get a deadlock). One way or another the threads need to share the data and not crash if one decides to clear the buffer while another is reading it.
