Feature request: number of buffer's channels from info~
Possibly not the first this I ask for this. The current impossibility to get this information from info~ seems completely absurd to me.
And not the first time I answer this question:
Send the getChannels message to mxj buf.Op myBuffer.
Thanks Patrick, but I prefer to avoid mxj as much as possible. I have experienced unreliable patchers with mxj and by the way I really don’t understand why this cannot be provided by info~, an object made to provide such information. It’s like buying a car and having to buy the steering wheel separately.
One way is to use sfinfo~ before you load your buffer, but it won’t work if you want to import mp3…
another way is to use gen~, there are operators dedicated to giving buffer channel numbers info inside gen~
----------begin_max5_patcher---------- 838.3ocuWssbaCBD8Y4uBM7rqGgrkuz2568OHSlLHIrLoHPCBmqSx2d4hPFj kbZRc6Kf7tKKKmkyx5WmEAx4OgaAweO9l3nnWmEEYDoED086HPM5oBJp0XFf crNGKdGL2pieTRwR4yMXqS.sjJFhBlGC1S4HIH91NKUJzljrHoSPMuzrnzte SJMa.O+9uAgN+umyjLTswPvODDsqsZZPxhCDV0cBbgzt4PXlx6pos5or05wT 3hj9XPE7DlJda82W8VzRdwrEvk8gmxV6gyZrV3ayloGl+mBU3GUGFW7JwOYB SPEl8gvWeD6CJIeMPIApwgMIFnIEdYPA9Y.En+thEcPQGVn7Aghe.KZIblm0 Q.TSim3HuknAv64FGsdduHByJJoWj.+.ws9sVgpzxLmR2Q2djyLSa2rROsNa yoitJAVUvoVuqMe2buAXngTdwuvk9wAf2fYDVi.2hYRjrKf5UWh2iNRk2Efk oKFU+dTAdxEOZtNBTIHkblNHBVoVra6ToeKkHy+vXrfgZFYwspyww1bjPCv4 TeBp5JLmSCU0mSULADiTijXIwFroI8NkT2HHLYvFgYHkONzVH3TZfqrZdXDM kpzdA9QRo7PPoDsFk4jFWJ.ziQkjJbqLTlDU0FJInJn+8QeJdf7KQ0Co6J9R LzWiGkNakuhoS0SPsSWtzjbWatgubigZm3komhdeNE+z0xyo4INEl5ecjsqO PUb.wXXZab8y4G26axYUIAAmPO.Mc2UAPsjlcYeLfl7U.T3+G.Ugh6wBKbFW JNVS47lKiqyu.1l82As67PV3xj+QPa5HP6oBeTBaJdtIj05GGya4GEENXxcS KNL5UEgjDV+6.2bhiOvvCjxxv5t1RUs5BekSQ4huc1IIexVQvuThJ565nQvk bcZuOCd.SazOW6rHmKJsOnCWrIyIz+wRSeDACi1yh6RCP87IhdVSCCtirZQl i1sZka7xcuMnTUP7G71dVBb2Z37Q+xD8WuN7rDu264blO9o5iEHx9Ia8y1ur hAliXUi1A3puTCfVTMM0jl1t8J1+meSwF2ERvrH3PhUGNdFgR2d6IdxDjI8e LvynyHRmShBBuAcdpCkAcbNnaygcZp71ay9MGzd5xC -----------end_max5_patcher-----------
though it gives you that data in signal, it might be reliable.
And you’re completely right about that lack of info with info~…
yeah thats why mxj buf.Op is here , but i had some problems while trying to receive channel data in realtime dynamically . sometimes i get strange results like 0 . as Patrick suggested [sfinfo] comes in handy .
i would also love to reverse [buffer] directly .
the big drawback with sfinfo~ is that you need the sound insied teh buffer~ to come from a soundfile.
Yet another (counterintuitive…) way of handling this is to use [polybuffer~] for that buffer…
----------begin_max5_patcher---------- 493.3ocyU9raiBCDF+L7TX4yrUfAZS5sduuAqVEYBSRbEXirMYSaU2m80d.R S+Spfl1ndwHOdxLe9W9X3wv.ZgZGXnjqI+lDD7XXP.FxGHnee.sluaYE2foQ qAiguFnQcmYgcVLNaHhp0VAV68MPWYoTxe5ORThopJt6WIYC4uRIsRdMlM8F sfWMbRC2tbiPtdgFVZ6JVZ7rKhiHIoW4ejGiabg12BYasP55OJV1AsvHd.aQ By8a1mamXwjS7AeJLzuDMRXHg+5tLugEOTQj1Mj7iijnigE1IgktGYy8qr3u Drv9DX4Xdjx15loYSl+ovQVdpm.on8HK4moIQ6JKPpDF6zsI4mhKYFhkKwUV xjvR5YvjvaZ.YIoT2VeqR0bAWrZZdlzSANrN2BK6moooQUceQ6pUf9eDkD7P pxAIgj+7IencpfKW+9SdNEp089FCIvGL3IYRCd5iZ3agxENI5Z5Bt0pEEtWb L8rqGdATnt.vaSLF.w8.zQ0PqDxW+oN7F4i+x+ILpV8xApMLVl77kpDLVGxs Bk7vjbeRijrOoMhxR.Oe39UJL7hpCT4a7DiUO4iQNuTyemxY9XjyYSMIiPM4 mM0j9MxlNesaf4VPa5KIJD2rj6TZ+1KivsBY2VrhTMrULj+rPe0dJ7+.QOoT uB -----------end_max5_patcher-----------
vichug , how to dump other buffers (lets say ive got 2 samples inside) ?
it’s all inside the polybuffer~’s help ([info] tab). Basically when you dump as idid, it dumps a lot of things, and in a "stream of list" format which you can more or less direclty feed into a [coll].
yes , a "stream of list" . ive been so stupid to dump out that into a [message] object ! laugh of myself . thanks !
Thanks for the information about gen~ vichug, this is very interesting.
you’re welcome !