rbrt

-its a sample player entirley done with gen~ and a pathetic name.

-its called 'cooler then groove~' because the groove~-external has been driving my NUTS

for quite a while now ,mainly because its extremly hard to get groove~ to do what i

wanted it to do when playing back samples in reverse.

-besides, its should do its job as a player for drumracks,because it nicely crossfades

between the 'old' and the 'new' when you retrigger a sample.thus,it doesnt make that fat

I'd be grateful for feedback regarding performance and usability.

-its called 'cooler then groove~' because the groove~-external has been driving my NUTS
for quite a while now ,mainly because its extremly hard to get groove~ to do what i
wanted it to do when playing back samples in reverse.
-besides, its should do its job as a player for drumracks,because it nicely crossfades
between the 'old' and the 'new' when you retrigger a sample.thus,it doesnt make that fat
bassdrum click.

cooler-than-groove

Hi, Thanks for sharing! This is a great tool, it 

 working well [it being the gen~ object] for me in a patch for a DJ-type platform I am working on, but now it has stopped outputting signal [sound]; the other outputted elements seem to be behaving as it should.

**I HAVE REMOVED THE PATCH DUE TO IT BEING QUITE BROKEN AND POSTED INCORRECTLY**

Hi, Thanks for sharing! This is a great tool, it was working well [it being the gen~ object] for me in a patch for a DJ-type platform I am working on, but now it has stopped outputting signal [sound]; the other outputted elements seem to be behaving as it should. 

**I HAVE REMOVED THE PATCH DUE TO IT BEING QUITE BROKEN AND POSTED INCORRECTLY**


 being the gen~ object] for me in a patch for a DJ-type platform I am working on, but now it has stopped outputting signal [sound]; the other outputted elements seem to be behaving as it should.

Any idea why this isn't 'making sound'? The gen~ object you made is located in the [CTVgroovegen] subpatcher.

Try using "copy compressed" when pasting to the forum.

nice, but are you sure the xfade is not destroying the attack of the next sample?

I know what you've been through with groove~. it's hell if you want playback forward, backward, palindrom, crossfaded etc + showing playing position. Pitchshifting is now another + for groove~ but it needs some serious bug fixing in the latest version, at least for what i ve seen on windows so far. O.

nice, but are you sure the xfade is not destroying the attack of the next sample?
I know what you've been through with groove~. it's hell if you want playback forward, backward, palindrom, crossfaded etc + showing playing position. Pitchshifting is now another + for groove~ but it needs some serious bug fixing in the latest version, at least for what i ve seen on windows so far. O.


@BENNETT:I will have a look at your code very soon.I did the whole thing in gen~ kind of to show off how nicely it works,anyway,I did a version that uses 'generic' msp for some things and gen~ for others...its more efficient since some stuff (the ramps used for x-fading for example) are still more efficient in 'generic' msp...should I share?

@11OLSEN : should work fine with the X-fade,the 'previous' sample is faded out into the 'next' sample, the attack of the 'next' sample is not smoothed in any way..

I think the new groove~ has a lot of potential,although the any other than 'basic' timestretching is quite expensive in terms of CPU usage.I do hope that showing the playback position will be integrated at some point,I dont understand why its not already...

@BENNETT:I will have a look at your code very soon.I did the whole thing in gen~ kind of to show off how nicely it works,anyway,I did a version that uses 'generic' msp for some things and gen~ for others...its more efficient since some stuff (the ramps used for x-fading for example) are still more efficient in 'generic' msp...should I share?
@11OLSEN : should work fine with the X-fade,the 'previous' sample is faded out into the 'next' sample, the attack of the 'next' sample is not smoothed in any way..
I think the new groove~ has a lot of potential,although the any other than 'basic' timestretching is quite expensive in terms of CPU usage.I do hope that showing the playback position will be integrated at some point,I dont understand why its not already...


Im new to max, and have made some fundamental mistakes in posting to the form on this, sorry for the long code [without compression], scrolling.

Don't worry about this patch, its not worth saving in my opinion, and its messy, its not fit for collaboration I imagine.

THE QUESTION I HAVE, I can now simply ask it:

I want to use your [gen buffer system] in a [bpatcher] for use in a larger patch where numerous instances of that particular [bpatcher] may appear. To do that, I want to name the buffers differently, perhaps using a #variable.

I attempted to create a new name inside your gen~ patch using an {insidename} message. This is when problems are seen for me, I dont know enough to troubleshoot the problem inside gen~.

Are you able to get it working with an {insidename} change to the internal (within gen~) buffer's external buffer reference name?

Thanks for getting back me/us and thanks for sharing your awesome work!

Im new to max, and have made some fundamental mistakes in posting to the form on this, sorry for the long code [without compression], scrolling. 

Don't worry about this patch, its not worth saving in my opinion, and its messy, its not fit for collaboration I imagine. 

THE QUESTION I HAVE, I can now simply ask it: 

I want to use your [gen buffer system] in a [bpatcher] for use in a larger patch where numerous instances of that particular [bpatcher] may appear. To do that, I want to name the buffers differently, perhaps using a #variable. 

I attempted to create a new name inside your gen~ patch using an {insidename} message. This is when problems are seen for me, I dont know enough to troubleshoot the problem inside gen~. 

Are you able to get it working with an {insidename} change to the internal (within gen~) buffer's external buffer reference name? 

hi BENNETT,hey thanks for liking my stuff!

the 'buffer' -object inside a gen~ patcher only references to a buffer~ 'living' in the main patcher.

so first of all,if you want a gen~-patcher to access a buffer,it has to be instantiated in the patch 'above'

then,if you want to change which buffer~ a gen~ -patcher is using,you dont have to change the 'buffer'-objects name inside the gen~.its the same as setting a parameter defined inside the gen~ patcher by the 'param' object:

lets say the buffer object inside the gen~-patcher is named 'hello'.but now want to access a buffer~ called 'hithere'.

simply send the message 'hello hithere' to the gen~ -patcher through the leftmost inlet,now gen~ will access or work on 'hithere'.

the 'buffer' -object inside a gen~ patcher only references to a buffer~ 'living' in the main patcher.
so first of all,if you want a gen~-patcher to access a buffer,it has to be instantiated in the patch 'above'

lets say the buffer object inside the gen~-patcher is named 'hello'.but now want to access a buffer~ called 'hithere'.
simply send the message 'hello hithere' to the gen~ -patcher through the leftmost inlet,now gen~ will access or work on 'hithere'.

i have a small issue, I would like to control the playing speed of the "Gen Groove" via a inlet to be able to variate it as fast as possible, I try to replace the parameter box inside the gen patcher with in 3 but it does not work du you know why ? 

Thanks again for this really efficient patch

Thanks for Sharing this,
i have a small issue, I would like to control the playing speed of the "Gen Groove" via a inlet to be able to variate it as fast as possible, I try to replace the parameter box inside the gen patcher with in 3 but it does not work du you know why ? 
Thanks again for this really efficient patch  

cooler than groove~