I just updated the binaries. The macro issue should be sorted now. On top of that I’ve updated gentable. Note that the correct way to specify colours is to use tablecolour:n(), where n is the table number. This means you can use names or RGB values to set table colours. Gradient for VU type tables can have as many colours as you like now. Simple use the same colourtable:n() system for those. Check out the heinous VU meters below!
Pre-release Cabbage 2 for testing - part 5
That is ghastly! Works great, thanks!
1 Like
A bit of a problem in the latest binary:
The problem is, when any widget is clicked for editing, it is being updated and rewritten in the code, on the line before it. Si it either overwrites an existing widget entry or introduces a new entry on an empty line.
Also, couple of questions about the XY pad (I think you might still be working on these) :
- What happened to the buttons that where there at the bottom? Drag and release for free motion or between set point.
- The Y value is inverted. YMin is all the way at the top, and YMax is at the bottom.
It seems my macro fix had undesired effects on other parts of the code. I’ve reverted so you can at least continue to use the GUI editor without a problem. I haven’t got around to adding the drag and release option. I was hoping no one would notice!! I’ll look into the Y value issue when I get a chance.
I have pushed a fix for the macro issue, I think. It passes my tests, but I would appreciate it if you could try it with some of yours. Just uploading now. Might take a moment or two…
Works great!
I’ve got an issue with groupbox in Cabbage2. It seems to draw the outline line regardless of the linewidth parameter, and (more importantly) it draws the line separating caption from content. In Cabbage 1 I could have just a “featureless” groupbox. Did the keyword for specifying line thickness change perhaps?
<Cabbage>
form size(863, 810), caption("VST_MIDIator"), pluginID("vmid")
image bounds(0, 0, 863, 810), shape("sharp"), colour(5,15,20)
label text("port"), bounds(10, 10, 80, 12), identchannel("port_id")
groupbox bounds(5, 30, 853, 81), plant("plant_parm1"), linethickness("0"), {
}
</Cabbage>
<CsoundSynthesizer>
<CsOptions>
-n -d -+rtmidi=NULL -Q0 -M0 -m0d
</CsOptions>
<CsInstruments>
ksmps = 64
nchnls = 2
0dbfs = 1
instr 98
endin
</CsInstruments>
<CsScore>
i 98 0 86400
e
</CsScore>
</CsoundSynthesizer>My bad. I’ll upload new binaries later today. For what it’s worth, outlinethickness() will control the thickness of the outer line, while linethickness() will control the thickness of the line under the groupbox text. Note also that you no longer need to name plants. Opening and closing curly brackets are enough:
image bounds(10, 10, 100, 100)
{
//sone controls
}The OSX link is currently giving a 404 error…
Should be Ok again now I hope? If not it will have to wait until I return to my Mac…
Got it. Thanks!
Unfortunately this doesn’t run on 10.8.5.
Cabbage Classic does though…
Hey Rory, why do the plugins export themselves as having 64 channels?
Also, is there going to be support for 32 bit plugins? AudioMulch on Windows only recognizes 32bit plugins.
I’m having some issues with the multichannel code. They should only show the number of channels described in nchnls, but it’s ongoing work. I will try to get a 32bit version for Windows, but I can’t promise a full version of Csound as it is no longer supported on Win32. I’m shocked AudioMulch doesn’t support 64bit plugins on Windows.
Ross Bencina (AudioMulch) needs to get this sorted. It’s been promised for a while.
Correct me if I’m wrong, but on Windows, when you’ve built your application in VisualStudio, isn’t rendering the application as 32 bit a simple task of switching the active target build to 32bit? Are there dependencies that stop you from doing that?
A couple of things I noticed. As Iain mentioned, Cabbage 2 doesn’t run on our current OSX version. But it does work if I switch it to open in 32-bit mode. Now the strange thing is, when I export some code as a plugin, it is recognized as a 32bit plugin in AudioMulch, but is unrecognized by Reaper. But Reaper has a built in mechanism to bridge 32bit plugins into a 64bit application. But it is unable to do so with Cabbage plugins.
It’s easy to switch to 32bit, but one then needs a 32bit version of Csound to link to. Supporting multiple architecture on OSX is not that tricky, but it is on Windows.
I’ll look into the 32/64bit plugin issue on OSX. It seems that supporting both plugin types is proving to be a challenge.
@iainmccurdy, @Thrifleganger, can you try again with the latest binaries. I have specifically targeted 10.8, I hope this should mean they now work on your systems.
@Thrifleganger, I’ve been testing the plugins here and Reaper will only show the number of channels defined in the .csd file. AudioMulch seems to, more often than not, show the maximum number of available channels, i.e, 64. There must be something odd in how AudioMulch is reading the number of channels. The strange thing is it that is labels the valid inputs/outputs with parentheses. But it is annoying. In saying that, I’m not really sure how best to fix it. I would rather produce a single plugin that is capable of any channel config than several that are fixed configs.
Sorry for the delay in testing this. It seems to work without problem on MacOS 10.8. Thanks!