Cabbage Logo
Back to Cabbage Site

No waveform display

I tested with “Examples | FilePlayers | DiskinFilePlayer”, using Cabbage2 64 2.0.02 (Apr 30 2018)
edit: ^OSX

It opens the file, but the waveform isn’t displayed as if it didn’t load. Pressing keys makes the appropriate noise.

Does this not happen for you?

Ok, this is weird. Using the file unzipped straight out of the archive creates the bad behavior. The version of the wave I uploaded and now redownloaded does NOT create this behavior.

Even weirder… they both report the same md5 checksum.

:thinking: Not sure how to proceed here :joy:

I get the same issue on windows 10. I’m using an older update on it, but I only get the waveform if I close and open the window.

I agree, this is a bizarre problem.

I’m not sure, but this (at least for me) seems likely to be a directory location or permissions based issue. I had unzipped the archive into a shared folder where all of my samples are kept, but the downloaded sample I had provided was in my home directory. When I copy the shared location file to the home directory, it starts loading properly again.

I’m going to play with this some more later and see if I can narrow it down to an exact reason, it may not be cabbage’s fault… but if it is it’s probably an extremely rare set of circumstances. I have no idea if other people’s problems fall into the same category, or if that was just a similar red herring.

So that was also using the official release, but it does work with using one of the recent builds on a machine with the latest win 10 updates.

Thanks @Slappz, that interesting to note. @t_grey , can you try the most recent OSX build?
https://github.com/rorywalsh/cabbage/releases/download/vBeta/CabbageOSXInstaller.pkg
It’s still a little behind the current dev snapshot as I’m having CI issues. I’m currently in the process of moving everything to a different CI system. So I hope to have automated builds for OSX again shortly.

So it seems if it’s located on a network or a drive other than the main drive, then it won’t show up unless you close and open it again. That’s how you should be able to reproduce it.

That was also the difference between the two machines. The wave files on my laptop are on the C drive, but the desktop my waves are on the E drive. When I moved it to the main drive it worked. It may also have something to do with the sample rate of the files, so I’ll play with it a little more.

The other person mentioned their files were on another drive, so that gave me the idea to check.

I’m guessing a newer build fixes the problem, because it reads fine from a network drive with a recent build.

Ok, tested and confirmed still occurring with 2.0.03 Dec.20

Unrelated, since I’ve been gone for a while… is there anything new and fun I should be looking to play with in the new builds?

The build I pulled was less than a week ago.

Edit: Sorry about that, I pulled it from the list of recent Beta links.

@Slappz are you using builds from the Appveyor list of recent builds?

Yes, I just grabbed the latest green build.

Not that much in the way of new features, but @mauro contributed some very nice new look and feel updates. Widgets now have a flat look, which looks far more modern than the old style. And the IDE can be completely themed now. I’d say the IDE is in a much better place now than it was the last time you were around, although we’re still stuck using the same JUCE code editor, which isn’t great.

Just realized I’m still seeing this behavior with gentable. Fairly minimal example attached.
gentable.csd (1.2 KB)

In Cabbage the waveform never shows up after I open a file. When exported as a plug-in, the waveform appears when I close and reopen the plug-in window.

This is on macOS 10.12.16.

I see the issue here. Actually, there are a few things. Leave it with me and I will try to get a fix to you soon.

[edit] the issue here is that displaying sound files should be done with the soundfiler object. gentable needs to know the GEN routine of the table at init time. And the tables should for the most part stay the same size. If you pass it another GEN routine it works fine. Also, you need to pass the gentable a table number when you declare it.

Got it. Here’s my particular problem:

My .csd uses the contents of a table for synthesis/processing. The user can either load a file into a table or record straight into one. (Only one table will ever be used at a time, but the user can switch back and forth). The file table is created with GEN01, the record table with GEN07 (but doesn’t really matter, I just needed a way to create an empty table to record into).

So what I need is a widget that can show either of these two tables. My understanding is that soundfiler can only show GEN01 tables.

For now I’ve changed the above example to use soundfiler instead of gentable. With this change I can’t get the waveform to appear at all. What am I doing wrong? I’ve compared with some of the examples that ship with Cabbage, and the only difference I’m seeing is that I’m using tablenumber instead of file. Either should work according to the manual.

Here’s the new example: soundfiler.csd (1.2 KB)

file() needs to be called for soundfiler. tablenumber() is an error in the docs. Thanks for pointing that out. For this to work, just do:

Smsg sprintf "file(%s)", chnget:S("filename")

instead of the tablenumber() stuff.

gentable can work with GEN01 tables, but they need to be known at init time. A work around would be to load a dummy soundfile that you include with your instrument. For example, if I do this in my header section it works fine:

giSampleTableL ftgen 1, 0, 0, 1, "silence.wav", 0, 0, 1
giSampleTableR ftgen 2, 0, 0, 1, "silence.wav", 0, 0, 2

Subsequent attempts to load files works fine after that. Note the reason there is a soundfiler object is for fast drawing of long waveforms. If you wish to display files that are more than say 10 seconds long, the soundfiler will be much faster than the gentable

That all makes sense, thanks. But why is soundfiler faster if you don’t mind me asking? I would think that because tables are already in RAM they’re faster to read and draw than reading from a file.