[Feature Request] Matrix read inside gen~ (jit.peek~)
Just a hopeful feature request,
that we will one day be able to read directly from a jit.matrix,
from within the gen~ environment,
ideally with options for high-dimensional data interpolation (as with jit.peek~).
I realize it may not make a ton of sense to everybody,
but if you consider the programming efficiencies of the SIMD like workflows,
you can utilize by working with matrices in max/jitter, especially with jit.gen,
combined with the options for reading said data in real-time, at high sampling rates,
it should open up for a lot of interesting ways of working with data in general.
My current workaround is outputting matrices, into jit.buffer~ objects,
allowing shared reference names between jit.buffer,
and buffer objects inside gen~.
Works well enough for some use-cases,
but it would be awesome if we could take advantage of,
the multidimensional interpolation features of the jit.peek~ object,
inside gen~ as well, when working with high-dimensional matrices,
hence this feature request.
I'm aware of the data object inside gen~,
but I don't see an easy way of using it to access outside matrices,
since it only stores its data internally,
and the options for high-dimensionality seem limited.
Hope it makes sense to other users beside me.
It would just make a ton of sense IMO,
and help bridge the gap between real-time audio processing,
fast data processing in jitter (SIMD),
as well as graphical workflows, using shaders, textures etc.
regards
Svend Ejnar / Gus
Hey Gus!
Sweet feature request — I do, however, feel that using jit.buffer~ as direct conduit between Jitter and MSP/gen~ works super smoothly. Since matrices mostly arrive at low priority, translating them to a Buffer we read from in codebox seems the most straight forward method. As much as I would make use of such feature — should a jit_matrix support ever get implemented — I personally assume that it may be too much of a hack, especially since most if not all operators need to be made available too along with a simple sample/nearest operator … the native peek() with the named Buffer is — mereckons — super intuitive. I guess, all it would take though, is to implement the jit.buffer~ functionality at the inlet so that this step is no longer asked from the user and within gen~ we would have a Buffer operator available like we used to. Are yo uthinking of more sophisticated usecases I am currently unable to imagine?
Best,
Timbeaux
I work a lot with audio "tensors" as an example, a bit obscure maybe, but instead of a multichannel signal say flat 64 channels times number of samples, or a 2d Data array, i might have a 10 dimensional sample with 512 total waveforms in one matrix. imagine a tensor with dimensions 44100 2 2 2 2 2 2 2 2 2. I can then read along time (dim 0, or x), as a loop, but change the interpolation position for all the other 9 dimensions, in effect creating a loop that can change in 9 directions at any moment in time, optionally it could be modulated as well, creating "infinitely changing" looped sounds.. This is really simple with jit.peek~ it takes an number of dimensional inputs, and interpolates between the samples at the locations specified by the dimensional inputs. I know its weird, but once you get used to the workflow its very straightforward.
When i want to create more elaborate gen~ patches, i always need to either flatten the tensors, and make use of multiple strides and packing schemes, and i just figured since jit.peek already exists, the core functionality is already "there" i guess, so maybe its not too hard to imagine it one day being available inside gen~
Sure jit.buffer is nice, when you just want to work with 2d data, or time * channels. I use it all the time, for look up tables, or filter coefficients, wavetables etc. But there is no simple way to extend the idea to 3d, 4d, 5d etc.. unless you manually pack the higher dimensional data into lower dimensional setups, either manually using strides or using jit.scanwrap and jit.dimmap setups. Its doable, just a hassle to be honest. I do it all the time, and it takes a while every time..
I realize i might be the only one who wants to use jit.peek in this way? And if i am, i get that its not exactly high priority :-) But it "would" be cool i think..
All i'd need to be super happy is something like this one day:
(genExpr)
// reference to external 44100 2 2 2 jit.matrix as an example, similar to Buffer or Data in gen~..
Matrix testMat("myMat");
// where x y z w controls location along that dimension..
y = peek(testMat,x,y,z,w);
// instead of the native peek(buf,index,channel) - just extend the idea to nD?
Either using sample indexing or normalized indexing like jit.peek~ and @interp options potentially..
Hi, Gussi. No, you're not alone. That would be very useful for me too!