Cabbage Logo
Back to Cabbage Site

Calling Overlapping Instances of Instrument that Rewrites f-table

#1

Hello! I am currently working on a project using the “liveconv” opcode that will allow users to convolve with an uploaded file and edit the sample region in real-time with rslider widgets. I am having an issue with calling an instrument that records the newly selected region. In my main instrument, instrument 1, I am calling a named instrument “Record_IR” ( using “event” opcode) to rewrite the selected sample region into an f-table being used by “liveconv”.

I would like to call the “Record_IR” instrument at k-rate using the ‘changed’ opcode with the region selection rsliders. When I do this, everything works fine until I stop the instrument, and run it again. Then Cabbage crashes. After doing some digging I realized it was from calling the “Record_IR” instrument when it was still running, although it sounded fine on the first run. I tried doing the same thing but putting a condition to turnoff the instrument if it was on and re-trigger the event, which solved the crashing issue, but produced audible clicks in the processing.

Does anyone know how I can trigger the instrument at k-rate but prevent cabbage from crashing on the next run, and why cabbage might be doing this?

I’ve attached the patch below, its pretty messy but the lines of interest are 193 - 206, and the “Record_IR” instrument is at line 254.
Thanks

CAB-SpectralModifier.csd (9.5 KB)

#2

Hi @BenWard74, welcome to the forum. I got the crash the first few times I ran this, but after I made a few code changes the crash went away. Then I ran your original code once again and it ran fine :see_no_evil: I’m now trying to get it to crash again…

#3

FWIW, the change I made was to this code:

kRecordLength, kRL_trig  cabbageGetValue "buffLeng"
kSkipTime, kST_trig      cabbageGetValue "buffLoc"

;Watch for changes in Region selection knobs
kchanged changed    kRecordLength, kSkipTime

;If changed, update GUI and record new region
;If this is called without conditional statement, it runs fine once and sounds great, but crashes on next run
if  (kchanged == 1) then

kRL_trig, and kST_trig are already trigger signals, so there is no need to changed them. You cn just do something like this:

kRecordLength, kRL_trig  cabbageGetValue "buffLeng"
kSkipTime, kST_trig      cabbageGetValue "buffLoc"

;If changed, update GUI and record new region
;If this is called without conditional statement, it runs fine once and sounds great, but crashes on next run
if  (kST_trig + kRL_trig > 0) then

In terms of function, this code change makes no difference. And like I said, I can’t even get it to crash now with your originl code :thinking:

#4

Thanks for the quick response! Hmm that’s interesting. I made the changes you suggested but I’m still getting the crashing issue. For me it always works on the first run, but if I trigger the Record_IR instrument with any widget, then when I stop and play then instrument again, it crashes. I thought it would be from Record_IR writing to the global f-table and calling multiple instances of this in short succession, but if that’s legal in Csound and you’re not getting that issue than it must be something else on my end. Any ideas what this might be?

#5

I can no longer get it to crash here. What version of Cabbage are you using?

#6

I download 2.9.0 as this problem started. At first I was on 2.8.0. The same issue happened for me on both versions.

Also, I just ran into the problem again but from something else. In my global instrument that is processing the convolution I have a cabbageGetValue to get the file name from a filebutton. If this line is included, it will crash on the next run just like the issue I had before. It doesn’t happen when using cabbageGetValue for other widgets, so it seems to be something with filebutton. Could it have something to do with Cabbage saving the filebutton’s string?

i’ve attached an update version below if you have time to take a look. I ignored the last problem and just use the update button to update the liveconv. Also cabbage won’t crash unless you press update at least once, so it could also have something to do with live conv, or my recording instrument.

CAB-SpectralModifier.csd (13.8 KB)

#7

I’ll take a look at this a little later today :+1: In the meantime, maybe @Oeyvind can throw his eye over it if he gets a chance, liveconv is one of his opcodes if I’m not mistaken… (not that I think that’s where the problem lies, but he might be able to spot the bigger issue for us)

#8

I can get it to crash on my work PC, so that’s a start :+1: And the crash is coming from Csound, but that could be because of something cabbage is doing. I can’t yet for sure…

#9

@BenWard74 Is there any way you can reproduce this using the command line version of Csound? It looks like the problem is originating from Csound, but I can’t say yet for sure. If you could reproduce the issue with a vanilla Csound file that would be great.

[edit] No need, it looks like the issue is originating from the filebutton widget/channel…

#10

Awesome! I really appreciate all the help!

I did some more digging and the issue seems to definitely be with cabbageGetValue and ‘filebutton’. I went back to the earlier issue I had with triggering the Record_IR instrument, and there is another instance of cabbageGetValue with “filebutton” in that instrument. I commented everything out of the instrument except for the ‘filebutton’ line, and it still crashed, so this definitely seems to be the issue. However it’s fine when there aren’t multiple instances of that instrument running at the same time. Not sure why it would have an issue in instrument 99 though since it is called once at initialization just like in instrument 1.

I am also using cabbageGetValue for another file button in other instruments, but have had no issues with that. When I replace the bad instances of cabbageGetValue and “filebutton1” with “filebutton2”, the problem still occurs, so it also seems to be a global filebutton issue.

.

#11

Can you forward me the simplest instrument you have that causes this issue? That would be helpful, thanks.

#12

Can you try the latest beta build? It should be ready in about 40 minutes from now…

#13

Ok sweet! Ya I’ll try that later tonight. I can also try and simplify the issue if that’ll still help.
Also where do I go to download the latest beta?

#14

Ok so I downloaded your latest beta 2.9.12, (I found your post for downloading betas in the forum) and that did not resolve either of the issues. However, I did manage to isolate the issue into a simpler cabbage file. It seems to be an issue with having multiple running instruments with a cabbageGetValue on the same filebutton. I imagine this is why even when I had it in one instrument, calling overlapping instances had the same issue.

Let me know if this still causes the crash for you and hopefully that helps. Thanks!

CAB_FilebuttonDiagnosis.csd (1.2 KB) .

#15

Thanks for this. It’s most helpful. I’ll start digging into this as soon as I get a chance :+1:

#16

If I use the trigger variant of cabbageGetValue it seems to work fine, i.e,

Sfile, k1 cabbageGetValue "filebutton"

Although it’s not a solution, it might provide a workaround. I think the issue is we are trying to update strings at k-rate, but Csound strings are technically i-rate only. to change them at k-time you must use specialised opcodes. The version of cabbageGetValue you are using works at both i and k rates. The one I propose using above only runs at k-time. Anyway, I did build a debug version of Csound to test with, but of course it works fine in debug mode. It’s most likely a memory issue, but I can’t see where. I’ll keep digging…

[edit] the same issue takes place with any widget that sends strings as values…

#17

@BenWard74 Can you try the latest beta build? It’s passing my tests here. :+1:

#18

It works! I downloaded the latest beta and I didn’t even have to change the code! It worked on the first run (well, technically second). Now both issues I had are solved and it’s working exactly as I intended. Everything else seems to be working the same as well. I’ll keep you posted if I find any issues.

Thank you so much for all your help @rorywalsh ! I had no idea the issue ran this deep so I really appreciate the support because I couldn’t have fixed this with out you!

#19

It runs both ways. Thanks for taking the time to report it it in the first place.