why cycling74 change read-buffer~ message???
old read message (till max 5.1.4) inside the buffer~ had a very big advantage…
it could double a mono file inside the buffer..
this utillity is necessary when you want to load a sample folder which may have mono and stereo files together..(if you had initialized the buffer as a stereo,it could load a mono file to both channels)
the new version of the buffer~ unfortunately has changes the sound of my patches because i have preloaded folders with mono-stereo samples (and now i hear all the mono files from one channel only)
as an alternative solution exists the "import" message which is not very stable (i have some crashes allready)
and is extremely slow when you want to load a lot of samples in sequense..
(also the selector~ + sfinfo~ combination(nr channels detection from sfinfo~ and routing of the signal with selector~) i don t think that is a very good solution espesially when you want to use it inside poly~.. is cpu more expensive..
so..can i somehow find the old version of the buffer(5.1.4)inside the max
one solution could be to use (replace) instead of (read)
Thanks for the report. The replace message is the way to go although there’s something wrong when you type the name as argument. I’ll look at it.
yes i forgot to mention that replace message has also the same problem with read … only import message can double a mono file inside the buffer perhaps because it uses quicktime ..
thanks,thanks for the reply Emmanuel….C:
I uploaded a new version on the incremental page. The old behavior should be back. Thanks again for noticing.
Hey, although Emmanuel posted a new incremental, I also came up with this simple mxj util that replicates the
behaviour you describe. Useless now, but here goes:
Enjoy (or not!)
oh~ oh% oh!
thanks pgk!! thanks Emmanuel!!
i feel strong enough now to swim into the bits and the bytes of the sound :>
nothing it’s useless till it’s useless
my little nastazia’s friend!!! he he!!!