I just tried this here and the first time it ran the debugger took me to Csound, which would indicate that this is a Csound issue, but after that it worked fine. I can’t seem to crash it again?
Do you mean a shortcut? Ctrl + / will comment a block of code?
I crashed it million times (Cabbage 2.7.16, Csound 6.16), 100% reproducible here, but you need to re-run Cabbage two times. So, run/save ones and then try again. It crashes on the 2nd run.
No, I meant the way of adding the file name to the path specific for WIN or MAC OS’s file separators (back slash vs. forward slash).
I think you can just use forward slashes for all paths, this seems to be cross platform these days. Let me try here again on a different machine…
I can crash it here too. It still brings me to Csound, which is odd, because if we remove the cabbageGetValue it seems to work fine 
Yes, it seems cabbageGetValue causes something bad in connection with copying strings. Please let me know if you find a bug or can suggest a different approach. What I want to do is have a default file name/path used when I trigger the normal button and overwrite that name when I use the file button.
To reiterate, I bumped into this issue when setting absolute path manually or with the CSD_PATH, no issue if I omit the path to the csd and just use the file name (which resides in the same directory as the csd file). The latter approach seems to work fine in Live (probably conditionally as you mentioned) but not at all in Reaper, where plugins crash.
So even on the Reaper side some grass is not very green - after this summer’s heat 
Actually I had quite some dropouts in Reaper (but not in Live) during my recordings - I plan to report to you on that but I have no clear bug identification. To compensate for these nuisances, I shall say that I now love Cabbage even more, since my fellow improvisers loved my instruments and found them inspiring to play with (big thanks to you Rory!).
Thanks for the info!
It looks like the string returned from cabbageGetValue is not freed, which causes the issue the following opcode. Just looking for a fix…
I have pushed through a fix for this. Your .csd file now runs without crashing. I also touched up some code in the other opcodes that might have also lead to some crashes. I didn’t have time to test thoroughly, but your code definitely runs fine 
Thanks! This is one of these cases where it feels like a joke. Now my code crashes Cabbage with the line commented as “OK” but not with the line commented as “not OK”. Could you please try that?
Leave it with me…
[edit] Can you try again? Both your versions work fine now…
Thanks! It works also here for the two strings tested. Of course I suppose your fix would work generally, or should I not? Was there something specific to the example string that was the problem the second time around?
Same issue as before. I will do a few more tests here just to make sure it’s Ok. Thanks for the report as usual.
[edit] just noticed another issue, which I’ve now fixed. Best to grab the latest beta again.
[edit2] We’re not out of the woods yet, just found another way to make Cabbage pulp…
Finally, we have clear skies! Passes me tests here, hopefully it will pass yours too.
Sounds great! Thanks for all the care and fixes - as usual! 
Could you briefly mention what have you done and in which area you’d anticipate any related potential issues? I’ll run with it and let you know in case of any issues.
Two things, I was a passing the channel pointer to the opcode output, which is a no-no. That was the easy part, but I also a discovered a memory issue in Csound if the channel string was empty. It’s seems odd that this would cause such problems, but in the end I could guard against it.
Thanks for the explanations. I always appreciate getting some sense of what is going on in the background.
This seems a good discovery. I don’t have a clue really, but memory leaks seem scary to me, and finding them surely helps increasing confidence for live use.
I’m sorry but another issue popped up now. The example below is similar as above, but adding file buttons. Please try both modes (file and save). They both crash Cabbage here. This was not an issue before (in ver. 2.7.16).
Btw. to revert back to older versions I still need to delete the app first. And I noticed in the past and now again that the button’s mode() identifier gets deleted automatically somehow (possibly when moving widgets). This is really annoying if I don’t notice it.
<Cabbage>
form caption("Untitled") size(400, 300), guiMode("queue"), pluginId("def1")
filebutton bounds(10, 10, 70, 20) channel("IO_SaveAs") mode("save") text("SAVE AS", "SAVE AS")
filebutton bounds(10, 50, 70, 20) channel("IO_Browse") mode("file") text("BROWSE", "BROWSE")
</Cabbage>
<CsoundSynthesizer>
<CsOptions>
-n -d -+rtmidi=NULL -M0 -m0d
</CsOptions>
<CsInstruments>
ksmps = 32
instr 1
SPathToCsd strcpy "/Users/Samo/Documents/test/0001/0002/0003/0004/0005/0006/0007/0008/0009/0010/0011/0012/0013/0014/0015/0016/0017/0018/preset.txt"
SFile cabbageGetValue "IO_Browse"
;SFile cabbageGetValue "IO_SaveAs"
SFile strcpy SPathToCsd
kFileValid init filevalid(SPathToCsd)
prints SPathToCsd, 1
endin
</CsInstruments>
<CsScore>
;causes Csound to run for about 7000 years...
f0 z
i 1 0 -1;[60*60*24*7]
</CsScore>
</CsoundSynthesizer>Thanks, these .csd files are invaluable for testing. I’ll get cracking on it when I get a chance.
I used ver. 2.8.8. Your link points to 2.8.7? Just tested again both. It doesn’t crash with 2.8.7 but it does with 2.8.8. Note that you have to press the Browse/Save As buttons and select an arbitrary file.
No problems here: