@antisvin random question about Daisy and reading from file - do you know if that is possible now with gen~ patches? Just assuming you have one and peeked at it
Moved this to a separate thread.
If you’re asking about OWL, it doesn’t support reading from resources in gen~ yet. It probably would be implemented eventually, but I’m not sure about the exact way can we make use of them. Or you might be asking about running oopsy - I don’t really know much about it, but I think it might be able to read from SD card.
Based on cycling74 docs, we should be allocating data from resources based on whatever metadata the buffer object provide. I’m not sure what happens in generated code in such case, since currently we’re just dealing with parameters, audio inputs and outputs.
I think we’re quite close to being able to use it. So if you’re willing to generate output from a simple patch that reads from buffer object, I can give a more specific answer.
Ah cool. Sorry I saw you had a Daisy thingie in some screenshot but forgot that Oopsie is the gen~ object stuff I should check. In anycase, i don’t have one and yes, more interested in OWL things.
Alright so, would be fun to try it. I am thinking I just create a gen~ patch as usual that references a buffer outside of the gen~ object and then compile then gen~ contents into C and then we edit the C to reference the correct data file, or something.
Sounds about right. So far I’ve had a look at gen~ sources and there are some data structures for working with buffer and data objects, but they use empty placeholders that are meant to have platform-specific code. It doesn’t look too complicated overall, so maybe I can get it to load samples using a test patch.
working on it now… Been a while but i am back. Just refreshing my templates
OK im back on track.
btw - [data] objects in gen~ are for creating some “buffer” within gen~ and filling it by some gen~ functions. There is also [history] which i think is like a single sample [data] object.
[buffer] on the other hand is strictly for loading a [buffer~] defined inside the Max/Msp side of things.
so here is an example:
im cycling a [buffer] inside gen (with speed defined by a knob that was rescaled)
and here is that DrumBeat [buffer] inside MaxMsp
[buffer~] with the name DrumBeat is loaded with a sample called “jongly” (some default beat from maxmsp)
If needed I can share the patch in whatever way is best.
Here is the compiler alert when loading the gen code:
/tmp/owl/owl-src-rkV64n/BufferLoad_gen.cpp: In member function 'int BufferLoad_gen::State::perform(t_sample**, t_sample**, int)':
/tmp/owl/owl-src-rkV64n/BufferLoad_gen.cpp:83:22: error: 'DrumBeat' was not declared in this scope; did you mean 'DrumBeat_dim'?
83 | int DrumBeat_dim = DrumBeat.dim;
| ^~~~~~~~
| DrumBeat_dim
make[1]: *** [/tmp/owl/owl-build-xbl4uI/BufferLoad_gen.o] Error 1
make: *** [patch] Error 2
ERROR: Patch build failed.
Starting to check out how other patches with Resources are done.
Ok, I suppose this is the test patch. However that error is not related to resource loading and so on, are you sure that [cycle] works like that? The docs say:
Reading the contents of a data or buffer can be done using the
[peek] , [lookup] , [wave] , [sample] or [nearest] operators.
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)
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