Thanks, this looks good as a starting point.
Hey @undefined,
I think Iāve got it to load WAVs, but it sounds like samples are played at very low frequency. Could you update the patch to make it play samples at native sampling rate? Not sure whatās the best way for that, but it might be something that youāve used with previous patches that played hardcoded sample data.
If youād like to test it yourself, currently it can only be used if you build patches offline. If youāre not familiar with that process or donāt want to deal with setting up compiler, it shouldnāt take too long to get this available for patches in public library. I just need to make sure that it sounds like it works at the very least.
Nice Iāll check it out, hopefully standalone patch compilation and upload isnāt that hard, donāt know if I have the time to set it up.
The patch I shared is meant to use the lich module knobs to increase and invert the sample playback. Maybe that works already. Otherwise I can make a hardcoded phasor frequency that plays the data contents in gen~.
Yes, hardcoded phasor speed that plays data as is would be perfect. If I can confirm that it works, we probably can have this in web patcher soon enough.
I was testing this with Genius that sets parameters to 0 by default, so it was not making any sound initially. When Iāve set one of them to maximum, sub-bass sounds was audible. I think that something is off with how itās been playing, but something definitely was loaded.
ive uploaded a basic setup . Also threw in a [samplerate 44100] object for good measure. Using a phasor with a 0.35 rate to playback a sample thats about 124 thousand samples long (3 seconds)
Iāve opened a PR for Martin to review, but so far it seems to work for me.
The [samplerate] object doesnāt seem to do anything useful (I donāt see 44100 in exported code) and we canāt neither change patchās samplerate nor support resampling in C++. But thatās not important here.
I suppose it should be possible to get the number of samples in a file and adjust phasorās rate accordingly, because otherwise you get wrong playback speed for a different sample. I.e. for a short sample that Iāve used I had to change 0.35 to 5-6 to have reasonable playback speed.
wow exciting! Canāt wait to try it, will check how to set that stuff up locally!
@antisvin hiya well i spent the entire day trying to compile locally but it seems super difficult on windows. Is it really simple if you use linux and follow the instructions on the gitpage or are there a lot of gotchas? i made a topic about the troubles and now reading the tickets.
** i made some progress but Lich is erroring out after the patch send.
I assumed i need to upload a file called samplzz.wav that is formatted as 32bit raw. I used the webuploader for that - hopefully it isnāt autoconverting to raw. Will try that after I am sure my patch loads from local compiler are fine.
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