Loading resources in gen~

,

Hmm maybe it only works inside gen~ inside maxmsp (it is sometimes very forgiving). I’ll do it the proper way

here is the error when using classic way of [buffer] being played by [wave] that is run by a [phasor]

/tmp/owl/owl-src-JMTRD3/BufferLoad_gen.cpp: In member function 'int BufferLoad_gen::State::perform(t_sample**, t_sample**, int)':
/tmp/owl/owl-src-JMTRD3/BufferLoad_gen.cpp:81:22: error: 'DrumBeat' was not declared in this scope; did you mean 'DrumBeat_dim'?
   81 |   int DrumBeat_dim = DrumBeat.dim;
      |                      ^~~~~~~~
      |                      DrumBeat_dim
make[1]: *** [/tmp/owl/owl-build-dKmZZk/BufferLoad_gen.o] Error 1
make: *** [patch] Error 2
ERROR: Patch build failed.

seems the same.

oh… there’s also an export error in Max/Msp

buffer: Buffer is not supported for code export. Use Data instead.

well that explains it.
I’ll check how to [poke] a [buffer~] into [data]

i’ve already used [data] and [poke]d it with just floats from a list… so this isn’t totally new territory.

As far as I understand, gen~ should be using [buffer], while [buffer~] is the MSP object . At least that’s the impression I get from this:

For more complex persistent storage of audio (or any numeric) data, gen~
offers two objects: [data] and [buffer], which are in some ways similar to
MSP’s [buffer~] object. 

So I guess you should be able to peek directly into buffer like in this example:

for some reason I was using [buffer~] into gen~ [buffer] because i thought that i was what was needed to show how resources are used inside MaxMsp and gen~ .
[poking] [data] full of stuff isn’t hard but how do we do it with resources.

A [data] object is local to the Gen patcher, and cannot be read outside of it. 
On the other hand, a [buffer] object is a shared reference to an external 
MSP [buffer~] object. Modifying the contents in a Gen [buffer] is directly 
modifying the contents of the MSP [buffer~] object it references. 

So I read that as MSP uses [buffer~] to load data into memory, then gen~ can use [buffer] to access that data. In our case [buffer~] won’t be used, but instead we’ll load data from resources. If you can update the test patch to use [buffer] and [peek] like in image above and it compiles, I might be able to get this working.

unfortunately like i discovered earlier the error from the compiler was related to the fact that we can’t export gen~ code with [buffer] objects…so we are kinda outta luck.

we should just use [data] … I’ve done this with a lich patch ages ago and filled it with values extracted from an SQ80 raw audio file… Only issue is how to replace that bit with a file…because storing lists of values inside gen~ is pretty annoying

I’ve found this thread on their forum and have the same conclusion - just use data and pass resource name to it, i.e. [data sample1.wav].

aha and then we define sample1.wav in the owl resource way?
(by adjusting the exported code)

updated the example with a simple setup that plays a [data] object named sample1wav

im in some twilight zone again… the compiled code keeps showing old names for the data objects even though they are fresh files exported from gen~.
I’ll try making a different patch on the site…maybe some caching magic.

*just renamed the gen files and uploaded em and the example is fine now

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.