You have to use OwlProgram version from my branch to test. Or you could just replace the 2 files edited in that PR (GenSource/genlib.cpp and LibSource/WavFile.h)
Resource file should be named just samplzz - I understand that don’t can’t be used in gen~, but using extension in file name is not mandatory. Raw can mean different things, but we actually load normal WAV files. Also, you don’t have to change format to 32 bit, it can be in the most common 16 bit format or 8 bit too.
yep I am using your branch of course.
OK i thought I had to convert to RAW as stated in one of the posts before.
going to dig into this again since i didn’t get it to work in July and still want/need it to do some fun stuff.
From memory - i got to use openware program locally, use your PR, and upload a regular wav file to the lich
@antisvin im back to where I was but hopefully the only thing missing is the correct way to upload the built patch to the Lich. At the moment the Lich just errors out after upload with an “F” on the screen if I use the windows build 0.1. groan Did the windows workflow work for the Lich before ? @mars ?
@antisvin hiya - so some progress and here is what I am finding so far.
Resource loading through the website seems iffy with my Lich ( Lich v22.5.rc1) - loading one sample will cause a readback error after the upload is done - dunno if it is file data type related or the size of it. Apparently its a twos (codec2 ? maybe some quicktime wav thing…its some maxmsp factory file) and its about 243kb - 124,439 samples length.
Another file is a bit smaller and is PCM S16 LE codec. Once the file uploads to the lich, the web interface just stays at 98% completion, but doesn’t show any erorrs.
Ok so onto the testing -
It works! I think only a tiny part of the file gets played back, maybe due to sample length allocated to the data object is some default. In gen, the data object has a syntax [data name samplelength] otherwise it defaults to 512 samples. I’ll take a look at the code, maybe theres something there for me to understand.
I’ll stick to this file format for now, since it works and bug you about samplelengths.
also need to build a windows firmware sender just to optimize this tool chain.
actually i see there are some functions to get number of samples from the loaded wav file - but not sure thats being correctly set…or im doing something wrong.
You must use PCM codec only (which is basially raw data), there’s no support for compression or anything fancy.
I’ll be able to take another look at this in a few days. Is there some way to tell gen~ that you want to read all available data?
not without maxmsp. I think Data is just some dumb buffer container that you allocate. I see that Owl stuff is trying to get the full wav length in samples automatically - thats pretty neat actually, but i guess with gen~ in mind, this isn’t expected by the user.
im trying to figure out why the whole file isn’t playing with your current implementation - from what i guess is that the export from gen~ will point the owl program compiler to what resource file to use and thats that.
anyway, if its some glitch in the code, maybe its not worth fixing in terms of gen~ export support for Owl since gen~ users will always manually allocate data size and have to look up the sample length on their own.
I recall that gen~ didn’t pass that samplelength parameter to generated code and for that reason we load full sample. It probably still uses something derived from that parameter (i.e. as a phasor frequency for reading data) and the reasult becomes invalid. This means that it becomes your responsibility to specify correct size of full sample for gen~. I will see if there is something that could be done about this.
oh its all good if you hardcode the gen patch generated .cpp export and instead of 512 make it whatever length you need. Hmm why wasn’t that working before
woah is that a gen bug. I was looking at the wrong place as to why the data buffer length wasn’t working
ok maybe it was my error but the exported data length you enter in gen~ editor gets passed correctly into the exported code… However, once compiled for Owl it doesn’t work. For whatever reason i tried setting the length manually 1 sample lower in the exported code and trying to compile again and it works
Ok, if you upload somewhere that WAV file and both exports, I’ll have something to look at. Is it only working if you set it to length - 1 or any number smaller than length or even 0?
any number as long as it is 1 sample smaller. I used audacity and maxmsp to get the sample number so I am trusting their count.
Other than that…wow this is working!!!
not sure about 32bit pcm file but whatever.
I see there is multichannel stuff too - that will be insane.
https://a.tmp.ninja/rDwcKhhp.wav dunno why this temp host renamed the file but thats the data file im using at the moment
ok more weird stuff is happening - i got a loop thats 84000 samples long - only half of it will play if use that as the data length. adjusting the size doesnt really fix it. Uploading a wav file that is twice as long will make the playback work - but if you set data length to 168000 then half of that one will play and the rest will be silence. Thats insane
ok one more experiment was a sample 362464 samples long and it only worked if data was set to 362463 . Hopefully these are useful clues.
@antisvin just a headsup - figured out why i was having those weird half playback issues - it is because the samples were STEREO. So it seems that causes some weirdness with playback and you end up with half of the wav being played back, and half of it is empty silence. Maybe something odd with channel assignment.
other than that all seems pretty sweet so far.
I’ve found a suspicious place that caused gen~ to erase buffer during reset (which happens when file is loaded) and the old size is the same as new size. In this case, old size is full WAV file size and new size is what you set in [data ...] arguments. I think that normally people would allocate a buffer larger than sample and playback speed won’t depend on sample size but rather sampling rate alone and this condition is not triggered, even though it won’t make sense with something like a wavetable. Anyway, I’ve disabled the code that cleared the buffer in my branch, but I’m not sure if it wasn’t needed for anything else in gen~.
Regarding stereo and multichannel samples, I don’t know if they work correctly as the patch you’ve sent me only plays 1 channel. But they do load and at least the first channel is played, so I would expect them to work.
Ah interesting! I’ll play around with it and make a better example with some multi channel wavs. It is very easy to make them i’ve discovered. As for data - since its a buffer you name and allocate space to and then fill it up with whatever, I was wondering how you are approaching it with Owl.
If a resource name exists with the name of the data buffer, then the resource file is used? and if not, then its just empty data that you name and use inside the gen patch I guess? I didn’t study your code but will take a look so no rush.