Hello Rory,
With beta version of cabbage 2, the soundfiler properties are not saved with DAW session (Reaper) so they need to be reloaded by hand each time reaper is started.
With Cabbge 1 it was working.
Hope this helps
Cabb2 beta :Soundfiler / VST does not remember sample files
Thanks. It’s on my to-do list.
I fixed the issue with the filebutton’s last file not being saved when saving presets and DAW session. That’s what this relates to no?
Not sure, I understand well. The path+filename loaded into the soundfilerl was not saved as preset or within the DAW. As a consequence, the soundfiler was always starting empty.
Hope this helps.
The path and filename are passed as a string i.e,
soundfiler bounds(10,10, 380, 200), file("piano.wav")
if you change the file during the runtime of your plugin then you most likely used a filebutton to do so. The last file opened by the filebutton will be saved. When your plugin reopens, a call to chnget with the filebutton’s channel will return the last opened file which you can then use to change the file() identifier.
It would not be possible to save the last file the soundfiler opened without overwriting the file() identifier in the code itself. If I get a minute I’ll prepare a simple example of what I mean. It sounds quite cryptic, but it’s simple enough…
I’ve updated the pre-release binaries for OSX. I’ll upload for Windows a little later. The attached instrument will save the last opened sound file and when the plugin is next launched, it will automatically load it to the soundfiler widget.
soundfiler.csd (744 Bytes)
@rorywalsh Thank You ! Not only it is a pleasure to use Cabbage because of its quality , but also, because you are so quick to answer user’s questions. This is really a great experience !
I’ ll post my first instrument as soon as I have implemented your solution. hope that some people will enjoy playing with it and help to improve it.
The new Windows binary will be uploaded in a moment. You can grab it from the same place as before…
Could you provide the link to the new beta please ? Somehow the version I manage to download is the previous one (the previous soundfile is not loaded into the soundfiler).
It should be the same link as before, but I never tested. Sorry, leave it with me. I’m afraid it might not be until tomorrow evening before I can check. Sorry about that.
This is the link, should be same as before. I just tested the .csd file I attached in an earlier post and it is saving the sound file that I load to the soundfiler when I save the session. When I open the session, the same soundfile is loaded on startup.
Hello Rory
@rorywalsh : Indeed your example works well with the new beta version.
However, I tried to make a VST out of your example LoscilFilePlayer which uses the same widgets (as the example “soundfiler” in this post). I had no luck with the filenames being remembered in the LoscilFilePlayer VST…They are forgotten from one session to the other (as my patch is based on that example… I have no more luck)
I don’t understand why.
Should you have little time, could you please check the loscifileplayer ?
Thank you a lot.
Is this the loscilfileplayer in the examples?
yes it is .
That’s because this instrument doesn’t try to load the last sound file that was opened. @iainmccurdy merely triggers instr 99 to load the soundfile whenever gSfilepath changes. It would need a little rewrite but I don’t have time just now. Leave it with me, if I get a chance over the weekend I’ll take look. But perhaps you can see the issue now yourself?
When I use loscilFilePlayer as a plugin within AudioMulch, load a sound file, save the patch, then close and reopen AudioMulch and the patch it does automatically load the last file. That’s curious isn’t it?
Ah, this is with classic cabbage? In that case the problem is mine to address! I haven’t tried it with Cabbage 2 but most likely that’s the problem. Thanks, better I take a look then you guys wasting your time on it. It’s important to me that everything work the same in this version as it did in the last.
Ok, I’ve looked into this, and I think my fix may break some existing instruments…
The old version of Cabbage would wait until the orchestra had started running before sending the filebutton string to its channel. Consider the following code from @iainmccurdy:
gSfilepath chnget "filename"
kNewFileTrg changed gSfilepath ; if a new file is loaded generate a trigger
if kNewFileTrg==1 then ; if a new file has been loaded...
event "i",99,0,0 ; call instrument to update sample storage function table
endif
event "i", 99, 0, 0 would be triggered after the first perf-pass as Cabbage would wait until the first perf-pass before updating the channel. I think this is a poor implementation. I think that the channel should be initialised before the instrument runs, as is the case with all other widgets, sliders, buttons, etc. Now, the reason why my example worked was because of init-pass fall through on k-rate conditionals. Consider the following
SFile chnget "filebutton"
kChanged changed SFile
if kChanged == 1 then
SMessage sprintfk "file(\"%s\")", SFile
chnset SMessage, "soundfilerIdent"
endif
On the first init-pass, chnset SMessage, "soundfilerIdent" will be hit because of fall through. Iain’s use of the event opcode, which only runs a k-rate, avoids any such fall through.
In all of Iain’s instruments that I’ve checked, a simple score statement calling his file loading instruments can resolve the issue and the sound files will be updated as one would expect. I’d like to hear back from Iain on this as it directly affects his instruments! If users prefer the old way or can think of advantages it has over the new system please let me know.
I am happy to make the changes in the relevant examples. I am happy to see chnget getting a sensible value at i-time now and I agree it should be implemented consistently for all widgets. In the past I have had to place init statements after chnget to prevent zeros causing errors (particularly with comboboxes).
Great. I’ll roll it out.