Bug on [sfplay~] while playing backwards?
Any idea why the (loop 1) message on [sfplay~] doesn’t work if the sample is being played backwards?
I have it looping normally, with a 1 on the speed input inlet of [sfplay~]. The instant I send it a -1, it plays the sample once more, then it stops…
----------begin_max5_patcher---------- 683.3oc0WssbaCBD8YouBMzWcxHjrjkZep+.8GnSmLXKhBYjAMBrqSyj9sWX QxWRsvJo1JtufLKvx4bfcW7y9dn4hMTIJ3yAeOvy6YeOOvjwfWaeOzRxlEUD ILMzRpTRJonI1wTzMJv9M3NS0D0hGX7x6ZnKTVWGkEca3jfoYl13naSlDf0+ N3GsKgU.9PL+wavYc94dAWwIKovPesgQp1eDI6WvHXimsl4qVx3UTE.znVih UJsI0S0TKTPns6ZcCUR4JhhI36A13jXCLivIlOgsMaWkdWr9D1Frw3K99llI +iRnSELNbvJX9GtBFFdYUPknrrh5PtvSgsFmaOJC6ZOpdkryQMZ0RQatixIy q.9dToA2mzv3JzYjmkDF+2tn4LLPyzYvmno.OS6gmwuYd16U.IqjatM4jwQu CFyo+Ti0+JznfrX.5PDFzg3YNOtiNugGGx4v2AmmuRoDbWA+yfzmXc7TxIuM uMKxvtwNmvKQm0ja56UNOqrwjXbt4SFPFb7wIS9aiK2WIHm03uSlmY+rxtOW xtZSxzW4nJgnNH7zQcV1O0dp1SMozO7RRY41Sm7QtnNnhtpriwYCUESFMU7x oGhZpqTc1JYsOyYlKwH9+HwnmpZx6qqHOMfBa1rjSycl3+BqG6J46pjQ2xkj 0cK7SeyrnsbUqr5CUyqUBySMggVKnunc4dRK3eTEi+5+dBnRF6Gp2RwplEca Y2ejHXmRUPkJFGRKr+jLXY6bdfUTP46mPtfIM4nK5uz9fgS90EbFBZhOXRWT 3jLD7DMd3Idn3AekgmvQ65C9TvAOpv4TpS9nglzAFoONnI4pBMwWUnI6BhFa ALRc8ZZir0k.PzOM3QQioa5DnKia6BO3G0PWy5leLXgzneVfR+lfUM1h5axR Q9l84E++.36YBNH -----------end_max5_patcher-----------
I can imagine there is something underneath the code for [sfplay~] that, when set for (loop 1), makes it wait for the last sample, to trigger the audio again. And since I’m playing it backwards, that last sample never comes, therefore it plays it only once, than stops.
Was just wandering if that’s an expected behaviour, or a bug.
I can’t even create the looping manually, because [sfplay~] won’t even bang when done playing if it’s set to backwards playback.
Use a groove~ instead?
When you’re working with negative speeds, you’ll need to use bidirectional cues to initiate a starting from a cue point with a negative speed. The refpages have been updated to reflect this.
To play the file back in reverse, you have to create a ‘preload’ cue in which you specify the cue number, the name of the file, the start point and end point (put the point that occurs earlier in the file first, even though you intend to play backward from end point to start point), then the number 1 (that’s a flag to tell sfplay~ that it should also preload some data at the end of the cue because you intend to play backward), and then the rate (-1 for backward at normal speed). So, for example, to make a cue #2 that will play starting 10 seconds into the file and reading backward to the beginning of the file, you would send the message preload 2 capture.aif 0 10000 1 -1.
Forums > MaxMSP