Cabbage Logo
Back to Cabbage Site

Updating Gentable crashes Cabbage

Hi there,
I’m coming across a problem with the Gentable Widget while I would like to display function tables loaded with audio files. I’m building a samplerish instrument and I would like to keep everything in RAM / function tables as I would like to avoid writing files to disk and also for performance reasons.

The Soundfiler Widget doesn’t work for me for a few reasons. I can’t send in and out points for the zoom from the orchestra. I also wasn’t able to chnset the channel(“start”,“length”) identifiers, so I couldn’t update individual start and ending points of individual samples in my waveform view. Another problem is that I can’t get the Soundfiler to display an assigned function table. I only get it to display files. I guess that’s why it’s called SoundFILER.

So the Gentable would be my choice. But the problem is that when I update the Gentable view with chnset “tablenumber(x:x)”, “identchannel”) after making changes like changing the Sample to be viewed/edited, the app crashes when the table size is larger than 44100. So I could only work with samples length < 1s, which doesn’t work for my purposes. The exact length 44101 crashing the app makes me think that this is not random behavior.

Is there any workaround this issue? For example, is there a way how I can avoid chnset-ing the tablenumber and still update the view of the Gentable?

Patching 60 Gentables together to view a minute long sample would be very desperate, quite a workout und probably not very nice to my CPU.

Thanks in advance!

A few things here. You can’t dynamically change the table once it’s opened. I know this is a pain, but it’s because of the way Csound parses tables. Am I right in saying you would like to be able to load a file and then skip to different sections of it at any point?

p.s. the channels associated with the soundfiler widget are only for incoming messages. You can chnset them. And zoom isn’t at all useful for this case either. :thinking:

[edit] Looks like I removed the option for soundfilers to load tables, I’m not sure why. I’m looking into it. Either that, of the docs were always wrong. The things about soundfilers is they work much faster for larger sounds. So I am inclined to add support for tables back to them…

I’ve updated the soundfiler widget so that it once again works with tables. I haven’t pushed yet as I want to finish another recent feature request first…

I’ve added samplerange() support for the soundfiler widget. You can check it out in the new build. I hope this helps.

Thanks so much Rory!!!
I’ll check it out. Looks like a solution. If I want to recall a selection within the sample I probably can help myself with some transparent/half transparent images on top.
Just to round it up, this is an example of what I did with the Gentable:

opcode  LoadSample, 0,Si
SFile, iSlot    xin
iLindex         = iSlot * 2
iRindex         = iLindex + 1
iSampleL        ftgen     iLindex, 0, 0, 1, SFile, 0, 0, 1
iSampleR        ftgen     iRindex, 0, 0, 1, SFile, 0, 0, 2
ftslice         iSampleL,90                                 ;load sample to Gentable table
ftslice         iSampleR,91
chnset          "tablenumber(90:91)", "waveform"            ;update Gentable
giSampleSize[iSlot] = ftlen(iSampleL)
String              sprintfk "samplerange (%d,%d)",0,giSampleSize[iSlot]
chnset              String, "waveform"       ;resize view to sample size
endop

So here I use one table and copy the new sample into it, whenever I need it, e.g. because I load a new one or change the “sample edit slot” etc. The original table has to be larger, than the sample I copy into it of course. So I initialised a table for a 180 second long sample. That’s how I quickly found out, that bigger tables crash the app with this one:
[chnset “tablenumber(90:91)”, “waveform”] .
But it actually worked on Samples <= 44100 smps. Sample 44101 was saying bye bye. Still would like to know, if that could somehow be on purpose? The Number doesn’t look like a coincidence.
I actually find that the Gentable waveform looks, much prettier. Is that the reason, why it doesn’t work so well on larger tables?
Anyway, looks like this is going to work for me.

I’m really exited about your software, and also about what I’m going to do with it. If it comes out well, I might consider going Pro with it. Building GUIs on Blender and stuff, we’ll see. 500$ for Cabbage Pro is a lot for me, but it might be worth it and who knows, maybe pay out beyond after all. And the incredible support that you provide for free adds a lot to that. I might hit you up with more questions and issues along the way. Anyways, BIG UP!!!

Hm? It seems like the trick to update the Gentable doesn’t work on the Soundfiler. I used the same code, but the Soundfiler keeps displaying the original table, after changing the table and chnset-ing the table number. This works somehow on the Gentable widget even though it’s a bit random: You can’t change the table number to be displayed with the command. And it doesn’t matter what numbers you put in. It still updates the view. If you change the table, that’s assigned to the Gentable in <Cabbage>, through manipulation in the Orchestra and then send “tablenumber(whatever number )” to the widget, it’ll display the changed table. Well as long as it’s <= 1 second.
I also wasn’t able to change the table that the Soundfiler was assigned to in <Cabbage> through the Orchestra. Do you think you there’s a fix for this?
Otherwise I’ll just have to work with a temporary file on the disk, that I have to keep updating whenever I change the sample that’s supposed to be displayed.
The Zoom function works though. Big big thank you anyways!

Hmm, the reason why gentable doesn’t support updating its tables if they are more than a second is because it’s quite a performance hog.

I thought you were creating a long empty table and then filling it with sample data each time you wanted to display a sample? This is how I would approach this task too. How long are your samples going to be?

I see, I though it might just be quite a task. Well, I think I’ll find my way around, with what’s available. And the stuff that’s available through csound and Cabbage is massive. I’m sure the workflow could be a little bit more fluent on rather synthesis based projects, but I’m really glad that I can actually do what I have in mind. The basic idea is already working, now I have to dress it.
As I said, I might want to look into selling this, if it turns out well, which is why I would want to stay as flexible as possible concerning the length of samples e.g., think beyond my personal ideas. Theoretically it might be a whole song, someone would like to import. In the end I’m limited to 6:34 minutes, as function tables just can’t any bigger. But that’s definitely a healthy limit.

Many many thanks for the support!

If you wanted larger functions tables we could build a custom version of Csound for that. I’m interested to see what you come up with.

I was thinking that to display the file I don’t need every sample in the table, basically just the graphic resolution of the gentable. But I’m guessing that just putting in every samplesize/gentablewidth-st sample wouldn’t look good. I probably would have to analyze the sample for peaks, which in cSound could only happen in real time audio speed. Haven’t looked at peak or rms opcodes yet though. But yeah, I could imagine that this is where you have to go on low level C.
Sorry, I just like to chat sometimes and you’re attending a whole community here. For now I might be good, but will be in touch.
Cheers

1 Like

Hey Rory,
Somehow when I use the new soundfiler zoom, it only zooms the beginning of the sample. I can’t move the starting point.ezgif-2-0d575d162c99

That doesn’t look right! I’ll investigate. Btw, I’m not sure it’s a good idea to set up identifier channels with the same name as regular channels :thinking:

[edit]

It’s working fine for me? I wonder if there is an issue in your code somehow?

Oh hang on, you’re reading from a file? I’m using table. Perhaps that is the issue. Let me check…

Nope still works. I’ve attached my test .csd, it’s confusingly called gentable.csd, but it’s a soundfiler example :rofl:

gentable.csd (1017 Bytes)

Hey, and thanks! So you’re script worked and I wanted to trial and error what makes the difference: It seems like it’s necessary to set the scrubber to a negative value. When I added the identifier to my script it worked until I set a positive value for the scrubber. Thank god, I thought something is wrong with my system!
Not an easy task to get around the random looking things when you’re just a musician with a few programming skills. So thanks again!!!

Edit: I was curious so I experimented a bit. The zoom dysfunction only appears if the scrubber is positioned somewhat in the beginning of the sound file:

Nice spot. I’ll take a look.

Hi @Stefan. So this issue is related to the fact that the soundfiler will try to move the waveform left or right depending on the scrubber position:

When we change the sample start/end times we also have to update the scrubbers position within the waveform viewport, this is turns causes the problem we’re seeing. I can disable the scrubber from scrolling through a waveform when zoom is set to -1, i.e, no zooming enabled. Would this work for you, or are you also hoping to use the zoom functionality?

For what’s it’s worth, I feel obliged to say that these soundfiler/gentable widgets are definitely not suitable as waveform editors. They are merely viewports. And while you can get useful info to and from them, trying to turn them into audio editors is futile. I know, I’ve been down this road :rofl: On the other hand, people continue to surprise me when it comes to the crazy things they have achieved with Cabbage!

Hey @rorywalsh, all good. The ability to zoom to whatever section in the soundfiler is all I need. I already created my own Scrubber with an image widget, which I hope doesn’t use to much resources. Will see…
I’m making a timeline with widget arrays in a plant. It looks like I can do a lot with the stuff in Cabbage, it’s just some work. I’ll let you know if I hit any walls. Thanks for looking into this!

When I hear widget arrays I generally get a little worried! They are useful, but keep in mind that Cabbage will query each widget’s channel data on every k-cycle. Things are worse if you have identifier channels as these are always string channels. So there are string memory allocations being made too.

You’ll need to do some trial and error I guess, but just thought I would make you aware of that. Btw, what do you mean by timeline? Are you adding markers across the waveform?

That’s the idea:


To gain orientation while moving through the soundfile. Thanks for the hint on performance issues! So I guess rather little detail will be wiser here.

Would it make a difference if I put all the changes that I do to the widgets in the array into instruments that I only call for the minimum time that’s needed to make the changes, e.g. when I zoom or scroll through the soundfile and otherwise have these functions by idle. Does that work?
These task will not be taking place while the instrument is actually producing sound, so I can seperate them.

:see_no_evil: Have you though of using an image? If all of those images have channels with them it might be a bit much, but if they don’t, then you’re probably Ok.

Looks great though!