You need to select the Cabbage output:
Would you mind changing this in the settings.json file to see if that works? I don’t have a multichannel card to test with. But yes, this needs to be far more robust.
I will look into this tomorrow when I’m back at work, I have access to a MIDI controller there.
Very much appreicated!
There seem to be some instability issues with ASIO audio on Windows. In the afternoon, I went to work, and apparently, the audio was working fine with ASIO (at least that’s what I had selected). When I came back at night without making any changes, I tested it again, and there was no sound. Sometimes, I received a message saying that no driver was selected, and it reverted to the default with the following message:
“primary Sound Capture Driver Cabbage DEBUG: couldn’t find previous audio device, resetting to default
CabbageAPP_host.cpp (897) iplug::IPlugAPPHost::TryToChangeAudio [Thread ID: 1368].”
After that, sometimes there was sound, but using the Windows driver, which is not ASIO. Then, I reselected the correct ASIO drivers—sometimes it played with a glitchy sound, and other times no sound at all. For this reason, it’s difficult for me to test the interface’s channels since ASIO doesn’t seem to be working properly or might not be working at all.
I have tried deleting the Cabbage extension and the folders where settings.json is located to refresh it ( C:\Users\ALE\AppData\Local\Cabbage ), but despite this, it still remembers the previous configuration and continues with the same audio issues.
The “Cabbage output” option is selected in the output settings, but the only thing I see is the mentioned message. Sometimes it compiles successfully (but without sound), and I don’t see anything in the console—just a black screen.
Thanks @Alejo, I have an ASIO device in work, I’ll give it a go today and see if I can recreate your issues here.
I’d say it’s a case that it’s using the default config rather than remembering anything. The only place it gets its info from is the settings.json file. If you remove that, or deleted it’s contents it will be recreated by Cabbage, and then updated whenever you update settings from vscode.
I can’t recreate any issues with audio, but I am seeing some weirdness with MIDI, I’ll take a deep look now.
I think I’ve spotted the issue, and made an update accordingly. I was only ever seeing issues with MIDI, but it was likely due to the MIDI devices not being correctly released, and I imagine the same thing might have been happened for you with regards the audio. Can you try the latest package once its uploaded? Thanks again.
I have tested the new version, and the issue remains the same. I’m attaching a short video for better clarity. Here’s what I did:
I’m attaching my “settings.json” file from Cabbage.
settings.zip (873 Bytes)
video: https://www.dropbox.com/transfer/AAAAAAdVJuDlbi9tI0s5j5qP3V8QaX_m0VCAfsxcFlnYgYfGAh8UcwI
Odd, I can see it in the settings file. Hmm, can you once again remove the cabbage settings file, and then double click the CabbageApp exe inside the CabbageBundle folder within the extension folder. It will be located inside C:\Users\NAME\.vscode\extensions. It will start in the background, but it will write a new settings file. You will need to Ctrl+Alt+Del to kill the process. Your settings file should now match what is currently available to you in terms of devices.
Then see if you can select the MIDI device. It’s also strange that you get no output - this would seem to indicate that the process hasn’t started, but if that’s the case why do you get sound. Can you open the developer tools once the Cabbage interface has launched? You can filter the message with Cabbage: to remove some of the noise. Maybe that will provide some clues. The key thing is that the two system are connected through a valid websocket. The dev console output should let us know if this is the case.
I was able to fix the MIDI controller issue by doing what you said, but I had to do something else. What happened is that after following the indicated steps to delete the settings and run the .exe application, the controller would appear but I couldn’t compile. What I did was go back to the previous settings file that I had saved, and that solved the MIDI controller issue.
As for the audio, it’s still the same; it only works with the Windows driver (which is slow and has glitchy sound) compared to the ASIO driver, and the console shows a black screen. I’ve attached screenshots from the Developer Tools showing when it works with the Windows driver and the ASIO driver. I´ve tested also with another asio single channel interface with no luck.
Seems to me like the websocket client is connecting in both cases. When I want to run ASIO drivers with my focusrite card, I first select ASIO drivers from the command palette, and then choose my device. Can you try this? Tomorrow I will prepare a simple exe for you to test your card with. This might be a little tedius for you, but I really apppreciate the effort.
To select the ASIO driver, I do this:
OK, I can try the .exe to test the sound card.
Actually, there is a new option to select the ASIO driver from the command palette. It seems that with rtaudio, which is the backend being used, that one must select the ASIO driver, and then the device[1]. If I don’t it seems to continue to use windows audio. If this works for you I can tidy things up and make it so that selecting an device with an ASIO in its name will automatically choose the correct drivers.
1If I recall correctly, we must do the same with Csound, which also uses rtaudio. We have to select the ASIO driver using -+rtaudio=ASIO and then select the device
Now I was able to get the ASIO drivers working, but I really don’t see the option you mentioned to first select ASIO-type drivers and then the device. I only see “Select Audio Input Device” and “Select Audio Output Device”. What was happening is that those options were only showing the Direct Sound drivers. What I did was edit the “settings.json” file and set “driver” to 1, as 1 is associated with ASIO and 0 with DirectSound.
“currentConfig”: {
“audio”: {
“bufferSize”: 256,
“driver”: 1
}
}
After saving and restarting VS, a new list of ASIO drivers appeared, and the audio worked fine. The downside was that the Wavestate MIDI driver disappeared from the list, and I had to manually edit the “settings.json” file again to include the Wavestate as it was in the previous setting.
Finally, the ASIO driver and the MIDI controller are working, but just in case, I don’t want to celebrate too soon, hehe.
I think a goal would be to make it easier for the user to select audio and MIDI devices without having to manually edit the “settings.json” file so much. I attach the audio options from the palette.
This goes without saying. Users shouldn’t have to edit that file at all.
My bad, I committed all files but the one that will show this option to users. I just triggered a new build. Can you test it when it’s ready? Hopefully we can mark the audio side of things as working. Then we’ll tackle the MIDI stuff 
Hello. I would like to ask a question about the possibility of having Cabbage 2 and 3 on the same machine. I haven’t been able to get both versions running on the same computer since Cabbage 3 requires Csound 7, and from what I’ve seen, Cabbage 2 doesn’t work with Csound 7. I’ve noticed that when both versions are installed, the last Csound installed is the one that gets recognized. For now, I would like to continue using Cabbage 2 with projects I have already started on that platform. Is there a way to have both versions working on the same computer (Windows)?
I agree it’s not a great situation but I’ve found a relatively simple work around. Install both versions side by side. Cabbage 2 seems to work fine even if csound7 is installed as windows seems to find Csound6 first in teh system path. If you wish to use Cabbage 3, just rename the Csound6 folder. If you wanted to you could create a bat script to launch the choosen version of Cabbage. For example this one will launch Cabbage 2 after renaming the Csound dir:
@echo off
setlocal
:: Define paths
set "CSOUND_PATH=C:\Program Files\Csound6_x64"
set "CSOUND_BAK_PATH=C:\Program Files\Csound6_x64.bak"
set "CABBAGE_EXE=C:\Program Files\Cabbage\Cabbage.exe"
:: Check if backup exists and rename it back to original
if exist "%CSOUND_BAK_PATH%" (
echo Restoring Csound directory...
ren "%CSOUND_BAK_PATH%" "Csound6_x64"
) else (
echo No backup found, skipping restore.
)
:: Launch Cabbage
if exist "%CABBAGE_EXE%" (
echo Launching Cabbage...
start "" "%CABBAGE_EXE%"
) else (
echo Cabbage executable not found!
)
endlocal
You’ll have to double check those path. And here’s the Cabbage 3 version:
@echo off
setlocal
:: Define paths
set "CSOUND_PATH=C:\Program Files\Csound6_x64"
set "CSOUND_BAK_PATH=C:\Program Files\Csound6_x64.bak"
set "VSCODE_EXE=C:\Program Files\Microsoft VS Code\Code.exe"
:: Check if Csound directory exists and rename it to .bak
if exist "%CSOUND_PATH%" (
echo Backing up Csound directory...
ren "%CSOUND_PATH%" "Csound6_x64.bak"
) else (
echo No Csound directory found, skipping backup.
)
:: Launch VS Code
if exist "%VSCODE_EXE%" (
echo Launching VS Code...
start "" "%VSCODE_EXE%"
) else (
echo VS Code executable not found!
)
endlocal
You’ll need to double check those paths. Anyway, now to alunch either simply run the corresponding bat file. Any other solutions would involve a disussion with the Csound core devs about naming conventions.
Ok, thanks for the batch and work around, I’ll try it.
With the workaround, I have been able to run both versions successfully. Something I have noticed about the sound: I generated a simple instrument in Cabbage 3 similar to the init instrument in Cabbage 2 that uses vco2. The Cabbage 3 version sounded a bit strange, and when looking at the spectrogram, I noticed something that appears to be aliasing (I’ve attached the image), which the spectrogram analysis of Vco2 in Cabbage 2 does not show, and it actually sounds better. I wouldn’t expect aliasing since Vco2 is supposed to be band-limited. I’m not sure if it’s something with that particular opcode or with Csound 7? Note: I tested it with C4.
[
{“type”:“form”,“caption”:“Keyboard Example”,“size”:{“height”:105,“width”:336},“pluginId”:“dz3”},
{"type":"keyboard","channel":"midiKeys","bounds":{"left":13,"top":1,"width":305,"height":102}}
]
<CsOptions>
-+rtmidi=NULL -M0 -m0d --midi-key-cps=4 --midi-velocity-amp=5
</CsOptions>
<CsInstruments>
ksmps = 32
nchnls = 2
0dbfs = 1
instr 1
iFreq = p4
iAmp = p5
aOut vco2 iAmp, iFreq
outs aOut, aOut
endin
i1 0 z
Wow, thats interesting. So this is the output from Cabbage 3 via vscode rather than through a plugin? Would you mind testing a plugin to see if it behaves the same? I suspect it might be something to do with rtaudio somehow, but I really have no idea. Actually, one way to tell if it’s Csound or Cabbage would be to write a file to disk and then check the sound files.
Yes, it’s the output of Cabbage 3 from VS Studio vs Cabbage 2 from it´s plataform.
I would try it, but with version 1.0.33, I haven’t been able to load VST3 properly in the DAW. When exporting, everything seems to go fine, but in the DAW, when I load the instrument, it crashes (I’ve tried different DAWs). The files I’ve generated are the ones attached in the images; the first one is what goes in the VST3 folder, and the second is the content generated in C:/ProgramData/CabbageAudio/PLUGIN_NAME/.
I just triggered a new build. There was an issue with the file paths. I’ve tested here and I was able to export, and load my plugin into a DAW without any problems. Can you try once it’s done? Also, let me know if you had. chance to try rendering the notes to disk. I’m really curious to see where the problem lies.
