has anyone found a way to display a waveform with sfplay yet?
i know this has come up before, but i can’t find a satisfying answer at the moment
i’m looking for a way to reliably display my soundfiles while using sfplay~ to play them from disk
as i write here
the groove~/waveform~ combination isn’t working so well for me with long, high-resolution soundfiles; the playback starts stuttering or max 6 actually crashes.
in live performance, i rely heavily on the visual feedback of seeing where i am in a soundfile at the moment, and which transient events are coming up next etc.
i’ve been able to make elapsed/remaining time counters and a progress bar to use with sfplay~, but have had little luck with actually displaying the sounds the past few months
any tips would be highly appreciated, thanks in advance!
What I do is creating in advance a short buffer (1500ms) for each soundfile. To do that, I read the file (much) faster and record the result in a buffer. It looks quite nice.
Then I use sfplay~‘s position output to control buffer~‘s cursor position.
Here is the patch, which is used in a much bigger patch. It needs 2 arguments (I use 1500 and 1500, in ms, but you may need to tweak that, depending on your hard drive). The message create audiofilepath buffername will fill the buffer with a waveform of the audio file.
Comments are welcome, as I’m not sure it’s really reliable!
----------begin_max5_patcher---------- 1903.3oc0bsraaaDEcs8WwTlrHAPQctyC9nEo.EnnK6l.zMMEATRirXpDo.I siSChQ+V5mV+R57fRhxVjZHk33HufTbHEm68L222Q9KWek2jr6EEdne.8Gnq t5KWe0U5gTCbU00W4sJ99oKiKzOl2zrUqDokdiL2qTbeodb4CgJR9aAZdVNJ Y05r7xjzaP4wkKD4nxEwonbQ7L0XuZUwq278WljJllcap9kPpFbd9MSTWiGi qFI81UY2VtTTpIhMitNtb5B4a7C4hokFlvmCxuDBXlS9T0Ip+XL5Oq9RIyzz a1jO9FFrgLlmkVlFuRnu0uKxmEmFW+dJNScOfTmjRR2PQfZrud80pCiNQjbc t3tDwmPStc9bIzoAUG.YLMTA31QL7yIhsRTTDei3IHVtX8x3oBzKADF8F.sc YceL.ZFC3JtOjRCXiPbLWiDf4TzgQBZfMHgY1K+7ZgYd7719trAjH8.jREeR ReOUp5Nz7jkBIuu3jPGJKPAKAL0QBz.3vb.3.mOvoDMAAiOLtPZFWXgQ6vEL aLeiVTi3BsW3xj3za7Fg7luLKtb3AolTydu2+8O+K5WkRQnxrLTwBoM9QnjR zmRVtDMQTY1WL68dcWDKfpfOBWihDRTa5djnKLcu7jTIJEmmlnVH6n84MPSH nNEAsIfQHOm1mG.SO.f09irwpCDc4Y0YdmM5.QrGazAjpK7VvkvKAqNMBR.p n6fTkXSfh.Qb9XdEh0HF42KLJQE+1ynHjboYlxbM5Ejtaxk6uUPpJd4vnV0u 3WV5WIyQuLAP+j7HQlAhHUeoXYg.IIRBxHfeBpeDruVJCZ0rTOCTbOwpoYKy xM2AONHhfkp6RIbRHwOP+IJ02ORtNViDbrSNwraDOzY3jP1oaxAsQdVXan4g sw+y4IwKOpkL84CiOzAWZ7su8gFiwDrCfXF8SV6ZojdfPEI2jJucmvlynryz ExUlljdrEb70l7MGaL.bri.m9H3Xl3NGeHMJZKH3GZheVm5p53g.At2Ao3sl ZLkkP8zuasPLCMOdZYVN5U5.AdsmC4LU3Mcgy7sly9krTw24MDNhgSxQrI+w 18CSurbCmKIEAZZtHVdROuGDfnGMZNicO.ZOCn96ssyAxQOefjoXeOfdA9Co YxKZpFVsUMBtNZDdTnNm.ZqvDzKXxjJP6dRcQJAE8Ok..LUnw.VMph4eFBZy 0oYmKVKRmgxjG6ad1.SCKQ7VUwBurL.cZ.iDQ1FhAFqKAS6nSvkI5TzjCZ3n lbpzoBas1mD+KKb41z0wS+qSwTSHyzJk1EWfugszn+181VBdSnZMGvFvrXge O1.eff47Nu0jC24E75ApxhLEEn0P3XjSpjbpxN8boWHyFp6IpUGfngAJqnsC Pj90AoVSUyIchTZFcTOZ.4d0AwTradPa8.I7azVfHCQT9N1BL4IESiWJLslN pZzI2rW8rB8k+oKi0S+Tcwi9Uit.hRZKrUiv.9bFN753b4anTj+AQZ7jJluc XegRBZePI.yCCGcvO8HPYPTy+99Trp8.dpo+4Tn0dSbJIh7bUpyh4IoyyZvJ n+wcLZZiEvauNdAmRGIpNsUBc6GdVSQQBEY4y1kkaOhFOX29znJQWBoUGIXm 4HgdNkvVuL9yOf.DwmfCwXbS9TnVl5B0r8dBBZErnmBXMp9m5dEB1XPuH9tM u3W7a5WpALpjdgQawD8EZI5eTNU0Pe87p2nTOZusoQI036ujTjca9zMSZUWF P6PnYhhxjz3xjrzZOS3dOyhjYyDo0M0uJY15LodXEInsGt0CuVz8ICsaFSJT dNzqL3CJVYKmDZAmnzQ5MqD3OlnTC46D1LiM.LSfZ8+HLiZO1zJy3VxgD0Mr korpswEJSuyO3UIVqtZf.0iIgnbS6HPUkZzQoGe2RNvYVAhRY6o.Eb.EnfgX slZ0hc2XFNmrivq5PoO2H3VO4kyHW3aic.VGWST3uZmFAlsLxNlROzPwFG01 bnyD0sBVgnSAVAHZ6UCAhxr.QejNvfhnTKPTdGU2HjZQ0AZmuLbTsNHBCiy2 G4XsmZc0RxUKQHyHhwoglcwB2mPeztXoE2itTUEaicSh6Drr0mMzAAK+ckfJ vnzB6ZLsZjA.XI1DoMwc.Kwl3kA2YAgXiCah6B4k3eNxmXuJcEgIfRBCO1mv HbyNaqci.UgW3xHmrhwgyLeeFIelsxQfajiTSE4HzCyg5813olhcK8bx5YmQ 5Arw4uuaomilVlCoGaVt.mRNvYN9.vX0MnZOOuWnACgIKvlPC.2sDq9YTbbQ NlaoG7olt1IFONASqE7Mdub7vCiXgJhH5QXa2EfFXSRyDGSOmb.iOV02rjxH 6B3Za5ljAJfKfaAiDz+Tbp5BW8DJ0CMDrhUAe4NQDabVE4NxwlPK5XQRpaVh 3a9YkTqFI5gFhEZaXEvcQsAVU1B2UgQaBZyuikCKPuah7Y7s+Tr17KFfwsXQ 1zpv30quSjWTQIZ52aU7GMdF0czWNuolK0sm1S8OogMOutGrdw4SWjTJlVda toso2G56csZd950+O.gwUqA -----------end_max5_patcher-----------
Here is an *old* patch I posted … in 2006 (!) in this thread :
very similar to Patrick’s patch : it creates a buffer~ 50 times smaller than the original sound file.
----------begin_max5_patcher---------- 3120.3oc2ck0jihiD94p9UP3ceZWOUij3bl4kI180c+CzwDUfMx1ZJL3.vU0 G6T+1WIk.VXygv1.UOcDss4Nyu7VJE02e7gEqR9BMagwOa7YiGd36O9vCxcI 1wCEa+vh8AeYcTPl7zVP+VXv52WrDNzgf706XwaeNktNGtMNVOYtzf3ijeQJ +z32Ktj3i6YwQzb4sCWrSVn7lmr5O9IzhSmXxw7xyzTry+7wGEerTSZc0w77 j3NnUjouf9rkjLxt7yJZEd94e8.EN+EqBh2tnYVAcIqfalUPWAqrNY+dZbd4 MLm9EIKrHK4XbnwFVD0HhFuMemAK1XeVG7LwEK4yhuHtvVJb8lj37L12j7r. eJ1a51URAQ0d5i8IKTtgwA6k2vE+VJKH59IiaCXVcbyFZ56FBFQWLAaZJACy wCSrlBLIl9F+YcAjrdGW6kxI1NPBLxQZQ3KMbswZBDWXnrXowBlPr.eosIi8 PwGxUfOGXqyyhXgzzx649jWo6RRYei+T4OIAtWhdIGdMH5HUceM5IQfTVdRu dHoWEWGEXa0KaiCEOWIA71l8IgzrmNv8lTbBors6xa3IkxwfbZ5yz3fUQ0NF aevV59frWTgxKDD8JDJcAuJg6rbeEEPtT13TRqr3f04rWoRJPkjpKZJuyuDm rRg0EaJ476ml8AC9sk90tLwwXPu1Vwge+506Xggz3NAX80scGptMRkc3Jq.t T.L7aC2q+qzzLVhJE9vhfCGT18CJWh.M+iD4MxYY0tXwvtPU6Jk9Jq75sp1a PJGTy4H5wTfz+hmyB3fbI3ikWZIhaIMIrk.Nl3ISDvx+Djyk0aiRV+BMTQEh CvGnwr3CozLta8f7Bpn5vgzMAGixeVUdgvO03w2Drl15E2n.3gEaSYgIwBhn 1UJ1c4i6yMjpPwYDGbngKNiyGGyVEjJP0BqXb4AySRhpenJAI2VHHlajkSyY .wxiPUdP19CoRqZkGD3jXW15zjnnZ2J3Hu1vQB4x50z2Xg46pEJSbD9oyNTJ BVTgQgrszr756KOXaV88TK0RUkPUi7Z6uKi85F7rpH9sYu66.Qzg.6x.5lJh qVM4a2KZsqsIWnskIa217skf3CkdGKrut+f3ZgpP2nHhHCngAqXaxMBihHQU +uc7D0LdhuV7zR4HBl94vf7.ErSA7DmvQvpR4p3p7EWwmqtlZWkHJG8qp1hE 6sJdJm6Ew7EbdFMRBv+txYdR.25cF0+cNJI4vfuu39uuhziF78kz+8MLM3sy uuJaVEUQ5DM3UZ3yb8.N18bPddJiWdG3foIwHc+JHvBR41cGsqpUaYalOtPb Bjay0WpQMlZabPlF2IR5nOtFxtxwZHbc2dXMalos5foqYyC0HJy+jqFsIIc+ 6FBkPi8zrLdRrYKlFWt+5uZf5ykKR5k0ya9BbY+QOvkrPVsR..AYgBediQtZ nTJsMOctVHkLMPJDSxvTOPELssruQPU5oq6TAZQC08ZgS7z.m+O8vQHvv7Xj 68QvHGtsZlDpWWATzwHzuclxrkvESTbAdrH1FFuncCjYe1ffYmirvFWu6fpy xN9ZvXLx7Z0qra.pOUdcDKtspIkXj33MKCxRNlttjeKpivnNfwqzMmEWMXCe tRc4ry6zvAoBpgrLQw0gUCWau5KCkhQZRw3OLTL2AsA5GJJ1VSL16BNa1zJ3 lZFVZPx1enTKzAjQeXnXqe3nXGMoX2OLTrmlTryGGGxBSOhldK9XPxjA3e6G KOxj6DEWLxSki5Tei3z2uSy3P+ynw.FF9FIhNd3s8P2FkrJHpXhmpt1FFs+G OAhCbt71DkvS.rblu1IxEdcRDLUTelmSqmqosm2xF+ERYl6ZuhAhiMzKJZNa ebIb15fhYY8IeMlC1UaqSxN7+4trweg5puR3XQfLm6g0fIdCcFEwWgbpXHxt XRWEVxF+czh9ECdNvWWzeM51LAZ27P9CdJVueSBMWDFBinQ68YBLtIPO2X4c sMWwvTRppHabAki6WcpeJtqVyDSXzRbkZSNVe3slKpedfhIzTXLOAhIe++RK lvSgXpstZ6PTvWMx2QMT56ufbCayuH2aRJaKO+nHirCTZnQ.+T3xmjzPCVtn I3BLf1hSdAY6ChhNoKHbmWM2m3NDyXSXz3fwtzrZHLu68JGhLiMK2+fiQZzn bNHncWu5FkCh7qe2wZMENyGwTyJwMHFni6eUSMCYOm4lkQouzctYkxAa4WVt ietYHmevUcIE4sg8G4pJtrqCmakY2II2jVZtyT5AJORVV0DE0kvwF55Pu4nA OQdyX4GaCxoZTKlErhLPWcicqu89bVL1m5I7MBZscBFcavw.CeiMmQLQzcpY 6Rxe23DYzNzf88FTD5aFZPSAzzV.yt.DBz63DKHIuIXXLv3o.KxS1tMpKeFP HNbQWJXW9oRLx1ig0YSJz+JmhL9VCaDES8tAxvwj+OitRVxEJ4oXYCXd0dKx XaiERP0e0Qj3lzLFb9+DkQytfL9a+WII..PQ+3hVB3f7Wx1c5WJ5Ly6Cbmar xHpq7QgwpECUWd8Njunmh5WWaVyTuybzgNCBWzsPSgiGmYL9THMRo8W5RIww 41VcZCzlycNiLIW.icWJGfJHe2oZX1wdefSsqDNbMm1T6lyzcKqQRtzi5c8N iJp828NWDPSqA34LgWAZDxePIa6GSJVvq12xBdcXEUSPy5HDIF.49gEXgQSb FeeJD7r5kUNf415D7w2RY16FWHgLmUKtgEuI48NSOg.sXuTGwibslN065zpg np5GCKcNxfyP14J.ssAr3tvF2hVVl.I0J8vncoSoL0k9Jt+pI5e0cqBP1i9P 1cp1JKSBt6T5.CIBrl488t8RqFVxcjAmwKV6Bp.leIWvNFUTAyr26FkqnIM. 4hH92bArMitM7JCfLuoNSy0AcJ5JCXLiclB+5SR5yUqzs5yvqxzHfbrbMcV1 3uTmFANNJWwlJxXXdjqH8yQYNoWdEktniBVQiTWqEEq4HtWtZDkb8LPbw1V9 RpProcmSKikxqdCqRUbUk6Uz..F8JeYabLBdcJTRJkzeMJw0kiEHwyGuDHLU P4rojwFirc7kDa0kwUo7vV0uLwqIfqRHz9b4zwOhXY40CeJECmQ6tV1l9xYB yV.71E3Nps2ZS1E670b15WpIRUUxqpGRz5jOu5v9Kl8e0XvJviTqQLVT7S99 4tr7EBTonFdDc4zDZaMLLiIHh0sUH4fqOvxb16zDVd+iNL7NSBl1sw4UlDZN eORgL9Ii06RRxnFAJccSWUNgUeohgHiGvfmSf4+DjuiQOZ7u1ErOXaLkiSbc AW9W6xyO7ye5S6gS3o0EmvSaRohOL9mkmwau81S7mEzg0YOweRc.qvatGGuh WubdiGrNqu2x92rrpl7pxUUxlZJeFuwx2we9FhVNkiRm0cWcVyFfaEM8gaY0 IMBhxVa5pQwa5Mcljdpul+.P870PPAz13hfoZUZoyBfogNA3h0KvEhXcoFTs EUQaKiAe00Tx3ROtZPOmQziI8fw5PO8Iu1yBOjvKENqriPPOYKJ5oX1acp15 zC5twADcT3NiMuXUpbOQTecPz9nmyPTrqk.CQ9E8Phc0ViAhZUybnEN.MTNv 7IOe9+DYkCyhTIa33LJrgX1E6UwPjp2ToXnioOgLczisFzC1c5nGcbUeFQO6 FxXuIidzxr7LhdLoG8CshmjPYDGcnmITe9tPOm6Fk.ASsJ5KF2psFCOn3QfC pRNfnxANiTnLhNbfyUELlfrU4fZCb4cjCLGAN.g7DzLFiT3.4VigVjyXHCJr Cf5opjAiTlD5D4FecZQXevRFFjK4VylVj0UoEU7hLGSvUaMBb.RmrUPNSWzO KcnmoKaEsfGqoKYk5w803six3FKVG8eQayqTvvnROHc7nLg0lXoSQzCrjOD1 T5gyCZsGGT0Vif+AcRFcByMVmZGltRGvDcU+Gf30Bxgvs5s8X4ViQ7KcrWHS m8BQqLiQSm.VGxY5FCLhVQilNus5DqlLcQiP5jQLdfYigwxQSyArGwPald52 XXdBc8klo1yXZl3qKMSLzJjEL.YjxzmLBLPgiRKKE5WrwXH.z0vah7Cn8PDM Mzi+8fbNW8Dh7YAuPPsHUaLBhW2ag9GgIyRqpJu1zbfYh7r+jpHHky9SoxY+ YT4x+Dpz1e9T3Om+7w+eoMWin -----------end_max5_patcher-----------
hi patrick and mathieu,
thank you very much for the help and the example patches!
patrick, in case you have time to answer a few questions that come up for me when i try your patch:
-where do the two arguments (1500 and 1500) go? i tried putting them in the loadmess objects.
-and the "create audiofilepath buffername" message, where should i send that? i tried sending a message like that into the inlet on the top.
-the [/] and [if] objects are giving me "inlet: wrong message or type" errors
so at the moment, i can’t get it to work, but i must admit there are several objects in the patch that i don’t fully understand. maybe i’ll do better tomorrow morning after some coffee..
your patch is actually pretty much what i’ve been using the past few years, you’re probably where i got the idea from in the first place! thank you for that.
do you happen to know why, most of the time, only the beginning of the waveform is shown?
i don’t get any error messages, and your patch is very clear, but unfortunately, most of the time, the waveform won’t fully load, and only the first few seconds are shown.
see the attached screenshots.
i’m using 24/96 wav files, mono at the moment, of a few minutes long, on a macbook pro with max 6.
your sfplay~ stops playing probably because your HD is too slow (playing 24/96 wav at 50x speed requires very fast access)
you can try increasing sfplay~ disk buffer size (2nd arg) (Patrick’s patch uses 26208000 )
or slow down the playback speed.
…or buy a SSD ;-)
you were right! i’ve increased the sfplay~ disk buffer size to 40.320.000 (it needs multiples of 20160) and for the moment, the patch is displaying any soundfile i’m throwing at it, including half-hour long 24/96 stereo files..
my next machine will be ssd based, but for now this is great, and if it stops working i’ll know what to tweak.
thanks again for the very helpful and clear example!
Save the patch I sent before as "waveformAF".
Save the following code as "bufferRuler.js"
// Patrick Delges
// Centre Henri Pousseur
mgraphics.relative_coords = 0;
mgraphics.autofill = 0;
var dis_width = mgraphics.size; // size of the jsui
var dis_height = mgraphics.size; //
var bgcolor = [.75, .54, 1.]; // default background color
var theDuration = 0; // size of the buffer (ms)
var intervalWidth = dis_width; // interval (in pixel) between increments
var minuteIncrement = 1; // duration (in minutes) between increments
bufferRulerInstantiate = 0;
post ("bufferRuler by firstname.lastname@example.org – Centre Henri Pousseur 2013\n");
bufferRulerInstantiate = 1;
dis_width = mgraphics.size;
dis_height = mgraphics.size;
// see http://cycling74.com/forums/topic.php?id=46577
// the size will be updated both in Patching & Presentation mode
// and in all views.
rectangle (0, 0, dis_width, dis_height);
for (x_pos = 0, minute = 0; x_pos = 60000)
minuteWidth = dis_width / (theDuration / 60000);
intervalWidth = minuteWidth;
//post ("->" + minuteIncrement + ", " + minuteWidth + "\n");
while (intervalWidth < 25)
intervalWidth += minuteWidth;
intervalWidth = dis_width;
function labelbgcolor(R, G, B)
bgcolor = [R, G, B];
Then savevand open this patch:
----------begin_max5_patcher---------- 847.3ocyW00aZCCE8Y3Wgk0dXShB14CHr2pT01qUaS6k0oJCw.Fk3fbbZYsp 829btFBocIYAXPGODi+9dO9bO95G61AOIYMOEi9H5GnNcdramNPS4MzYS8N3 X15oQrTXXXI+9jIKw8rco4q0PyQIrvXdZJxwiX9sseYVbRlNhqgIS2zpsI8u Vws6LFi94ltlkH0RVLzA9RkfEscoVwzSWHjyuUwmpsyykP6S5gbcBxKnD+7B GReRwxIBgExXwW33gKsGohGf8f5XlSgsJjElZdaO0sa9mdsEZxhmvUU65N04 5BoF2CgmvjyORTXnKfBfGUOJ3takTlcPyU2xkrIQvdQNwHTNCgMm+GrmvLES KRjn2QOqLGOx37hQPEZPMPFceHNNG.rrLMSb39sHhW32SxlMiq9RVDW0eYZK ..OHlwaDoIRCcbaHMGM6XZRbLOOb3UriUYZjdAGoDyWnQ49qwgVTMfUvfUym .0KNkVo3olUG3Yk.BpK35A.bP174vHUTJnCMZHvlbF2HjFbpUipCM0YJIJQt uv29gDttkDl8F1HRL5TiD2ytiOKQE+b097v5hwlYtTCDma3OQhTnbW7nMDr. pdHYRSggisjEq1siOTanWMHkOtJHw+.fD9CgroO2LGnByMHn7wp+1uUZrd3+ Uxi0jxwJkXG8tFZ79PZsNmi+HvG8ZjyRN0bVCAyrF6YtDErxiHaBGxnRv.cX iWLL5+wjIlp3LMGcCdv2ShxLiZv0WpuMjoYC9ZhLEEJtiqRK+ejyfu84KtxD JyjZzUl4Gmhd+0LkF47g9LwravnRwwm1TSrzPe60y1J0kYh2oNwjZh7rRbOm iIHpOgfnuAD0sRmzw1BZio8dxy8uZjZ6UOW9oM.kecuMpVrBfnhqbNFNEM.T rotAMpsgeqhai3L0YJ8eK2I.nN9jlhwnGb1+vpYRPP95GXCFTd6uDjRSxTS2 5XaewJZmQExS0BIj+Z4A49hAsPDFxkkkeCEo4JxfGQp73p01iaarG54ydnsv dxe6xYxdnswdbNalSaXOmuCqVcVQNqlC8uXNiNPqwF3yVsJO2hMKIXHFcvkI ph2bfMBG1pf9FVwuSrc7tPKLkQ4RajsxTVgs0ACwcy2mm59aaAZlCC -----------end_max5_patcher-----------
The difference with Mathieu is that in his solution, the files are always read 50x faster, so if it does work for one file, it will probably work for others.
In my solution, the speed depends on the length of the file, ther idea is to have buffers of constant length (1500 in the example). If it doesn’t work, then the buffer size should be increased.
If the file is too short, then it’s simply imported.
thank you very much for the additional info!
i will dive deeper into your patch the coming days and report back – very interesting to have several different approaches to look into.
i would just use a parallel buffer~ with waveform~ as display …
your js code returns several compile errors after copy pasting. It might be that the forum formatting breaks some characters… (like the "" for instance, which are the same i guess originally, but interpreted by js as ‘illegal character’. I have another error after :
). Could you please maybe upload the thing in a zipped format ?…
Sorry for that vichug. The .js is attached.
(And sorry for the delay, the RSS feeds on c74′s forums only have the 25 last posts, so I didn’t notice this topic continue during the week-end…)
no worries, thanks a lot !
erm… this thread is too weird for me to avoid.
a key advantage to sfplay~ is reading directly from disk and saving RAM. if you then use buffer~ alongside sfplay~ just to display its waveform, it is a very lazy/inefficient answer.
instead, if you’re willing to learn, you could use the ‘spool’ message to the ‘filein’ object(which reads from disk same as with sfplay~ allowing you to match proper context of functionality), and parse through the raw bytes of a soundfile.
i understand it’s not the easiest solution, but the information to help you is all easily available on the internet, for example, this makes it ultra-easy to figure out a max patch on your own that would save you ram for aiff files:
there is similar info. available for .wav formats.
you don’t need to know C or C++ for any of this info. to make sense, either, because all you’re needing to pay attention to is how to find which byte where(this addressing and ID of information within ‘chunks’ of an audio file only takes a very basic understanding of how binary information works… this knowledge should actually be essential for anyone working with audio files… there are many creative things you could do reading a soundfile in non-real-time without using RAM to analyze/read, for example, using a set/initializing sound-file which would inform real-time DSP over other signals later on…).
once done, i would then simply apply it to a multislider view(and you can even go by the information within the soundfile to set number of sliders, thus giving you the option to set resolution of display according to size of file).
just my 2 cents.
I agree Roman’s solution may not be optimal (RAM and time wise)
But using a short buffer~ (1500ms in my case), it’s not an inefficient solution at all. And you get some UI consistency with buffers.
Using filein is of course an option, but I’m quite happy so far with the way I did it. And I don’t have to worry about all audio file formats sfplay~ supports. Call this laziness if you want.
And As I know how to read RIFF files, I really prefer to learn something else :-)
"I agree Roman’s solution may not be optimal (RAM and time wise)"
oh shit, i didn’t even see that he had also replied(just the one-liner, completely missed it… i probably would’ve avoided the thread as i know how sensitive he is :D). sorry you made the wrongful and quick-to-jump-to-conclusion assumption that i was referring to his. i was actually referring to everyone’s(hence the words "this thread is too weird" referring to the entire thread…. to be honest, Mathieu’s solution is the only one that borders on being smart and elegant, though still a waste of resources…).
simply put, i was just simply surprised to see so many of the usually-smarter-veterans here do exactly the same thing i was doing when i was a beginner. that’s all. it’s not actually an insult, just a good objective perspective to offer amongst your very obviously subjective experiences(not researching the prob outside of max can force one into very myopic solutions sometimes… and i think that is what i saw quite evidently in this thread).
" I really prefer to learn something else :-)"
this is what Max excels at: letting you get as distracted as you’d like(i used to use it for the same reason). that’s all i was saying. not sure what point you were trying to make(but consider that since you focused on the most moot points of my post, perhaps you are reacting out of some kind of prejudice over something else? i don’t know where the ‘contrariness’ comes from is all i’m saying… since i only spoke the truth: that using buffer~ IS inefficient compared to what you COULD do, and that if one chooses not to learn about the technology they are invested in, there must be a certain amount of laziness involved: in such cases the focus is on the ease of the tech… and furthermore, i never actually said being lazy in Max is bad… if anything, this is what Max excels at helping people do more than anything else and it is quite clever for doing so :).
Hey Karaokaze, i have to say that here i fully agree wiht Patrick Delges. A 1500 ms buffer is worth ?… maybe 1.5 Mo ? (hah Max has made me too lazy to even calculate this. Or is it because i’m lazy that i use Max ? ;) ) and given our 4Go ram machines it’s not much, nearly nothing, and it is a great way to avoid inconveniences that doing it the "clean" way would lead to, as Patrick explained (using waveform~ conveniences and implementing exotic formats). Also, it is more than likely than one would not need a lot of those buffers at once, hence the little embarassment caused by the memory occupation.
In the case you need a lot (i mean hundreds) of those waveforms displayed at once, then, yes, it would be a good idea to begin doing an external.
"Max has made me too lazy to even calculate this. Or is it because i’m lazy that i use Max ?"
there ya go :) (it starts with the first part of your sentence, which influences you to sway towards the latter part… so i’d say a little bit of both at this point)
"i have to say that here i fully agree wiht Patrick Delges"
hey no prob, you’re all free to disagree, it doesn’t actually detract from the fact that i am speaking truth, and you are insisting on going with your own max-induced subjectivity.
my contribution to this thread was simply to get you to think about the most efficient(not to mention more professionally applicable) alternative. If you have no desire to ever think or be applicable anywhere outside the box of max, you should totally go with the inefficient and easy stuff. my contribution was just hoping you’d see how developers throughout history and in the actual professional realm of audio have done it(it was never my hope that you’d actually care ;D …i just saw it as my duty to give the proper info. rather than just the info. i would’ve been drawn to for a crutch as a beginner).
Where truth is concerned, a majority voice does not decide. Truth is truth: the techniques using buffer~ are in fact, more inefficient(if it is slight enough for you to not notice, that is another point entirely which has nothing to do with what i’m saying)…. so it is perfectly fine that we all agree to disagree on such a ‘subjective’ level.