Cabbage Logo
Back to Cabbage Site

presetChannel in .psts file

#1

Today I found that if I call some presets from the menu generated by

presetbutton bounds(320, 70, 110, 20) channel("presetChannel"), presetNameAsText(1) userFolder("quasi", "*.psts"), textColour(255), highlightedItemColour(10, 147, 210) highlightedTextColour(255, 255, 255), fontsize(20)

from REAPER it hangs without an error message and I can only kill REAPER from the task manager.

Comparing those .psts files causing that I found that they include

“presetChannel”: “C:\Program Files\Common Files\VST3\Cabbage\quasi\OneBar\Ngbaka-Maibo CB.psts”,

but those working properly

“presetChannel”: “”,

OK. I can fix that by editing the lines. But what sense does it make to write a full path of a .psts file into a .psts file? Wouldn’t it be better to ignore the channel?

And actually it is not the path to the file itself but to the last active .psts file before the “Save as” action.

#2

Very similar here. (Cubase 5 / Win7)
Cubase does not crash, but somehow the wrong sounds are loaded.
Haven’t had time to test this.
That’s why I haven’t posted anything about it yet.
Saving the path of PresetChannel in the sound file for no reason seems to lead to inconsistencies somehow.
If I remember correctly, it also worked better for me when replacing ‘PresetChannel’ with an empty string.

#3

Hi guys, thanks for the report. Does it help if you add presetIgnore(1) to the presetbutton?

#4

I already tried this. But as mentioned in another post this only prevents the channel being shown in the DAW automation but still writes the channel/value to the psts file. But I will try the empty-channel-name-trick of @jockel.

#5

Thanks rory for the quick response.
I tried that but it didn’t help.

#6

I fear there is still this problem here. I wrote some minimal code to illustrate this:

New_presets_test.csd (916 Bytes)

When I run this and save a preset with both buttons on, it produces a psts file like

{
    "All_on": {
        "form": 0.0,
        "presetChannel": "",
        "not-ignored": 1.0,
        "cabbageJSONData": ""
    }
}

So it correctly does not write the channel “ignored” but does write the presetChannel although it also has a , presetIgnore(1).

Even stranger, upon generating a further preset with all buttons off it produces

{
    "All_off": {
        "form": 0.0,
        "presetChannel": "C:\\Users\\Reiner\\Documents\\OwnMusic\\Cabbage\\NPtest\\All_on.psts",
        "not-ignored": 0.0,
        "cabbageJSONData": ""
    }
}

Now with the full path of the first preset.

At the moment I am trying to weed out the lines containg “presetChannel” from the psts files. But if I forget this or a user would try to create additional presets the latter version with the full name will cause REAPER to crash.

Is there any way to get presetIgnore(1) to work also on presetbutton?

PS: I tried also @jockel’s workaround, presetbutton bounds(20, 20, 110, 20) channel(""). But that makes the presetbutton widget completely vanish for me.

#7

Sorry for not getting back to you sooner @RZorn, I’m going to take a look at this shortly. I’ll keep you in the loop.

[edit] Can you try this sample file I usually use to test presets. NewPresets 2.csd (1.9 KB) When you launch it in reaper as a plugin, and first hit save, create a new folder called Presets in the plugin’s Content’s folder. If you save all presets into there it should work fine. I’ve not been able to crash reaper at all, and my presets seem to be working fine. One thing I noticed in this instrument is the preset button does not display the preset value when the session starts, but I think this can easily be resolved.

Quasiperiodic rythms
#8

Just to add my latest experiences with the ‘New’ preset system. I don’t expect them to be fixed, I also found a workaround, see below. But for Cabbage 3 it may be worth taking this into account.

For the new instrument ‘quasi’, Quasiperiodic rythms, I wanted exclude certain channels from being loaded when a preset is loaded. E.g. if I decided to have it in the ‘Chord’ mode I don’t want it to switch back into the ‘Test’ mode when loading a preset if that’s what is saved with the preset. So I used presetIgnore(1) but it did not behave as I expected. It still saves the channel to the psts file, just does not load it. But then it also does not load that channel when I restart the DAW (REAPER, but may be the same for others). So it reverts to the default in the slider or button definition, which in that case is ‘Test’ again.

In addition to the danger of crashes from presetChannel being saved as a full path, I would say this speaks for realising presetignore on the the save side, not for load. Or both having a complete presetignore or just keeping it off the psts files.

My current workaround are two python scripts (generated by Claude as I have to admit) which list and weed out the keys bothering me from all psts files. These scripts are also included in the directory quasi coming with the zip file.

#9

I’m glad you found a workaround for this :slight_smile: I haven’t started implementing the preset system in Cabbage 3, so I’m open to all suggestions. I have built 2 preset systems in the past, and I’m not entirely happy with either. This time around, I’m inclined to provide the basics, along with sufficient flexibility for users to tailor their own solutions to their specific needs. I think a consistent problem with previous attempts has been a wish to provide a one-size-fits-all solution, which I now see as futile. As soon as one checks all the boxes, new requests arrive that eventually start to stress the system and ultimately lead to problems. I’m hoping to avoid all that this time around :+1:

#10

I fully agree. I also think that a system which allows presets via code provided by the user is better than one which does this automatically for all channels needing a lot of exceptions.

I don’t want to overburden you with requests. But just what I would think would be really useful:

  • I like the tree structure of the new preset system. If there are a lot of presets (same for wavetable files etc), it is very helpful to not have them all immediately in the pull down menu but rather sorted by groups.

  • Csound is rather difficult when it comes to string processing. So if some commands would be provided which can access files (JSON, YAML or such) as dictionaries that would make it much easier to build on.

#11

I’ll definitely keep these in mind when I get around to implementing the new system :+1: