Anthony Palomba

I have just recently discovered BBCut, which does algorithmic 

beat cutting and rythmic pattern genertion. Pretty cool stuff, 

http://www.cus.cam.ac.uk/~nc272/bbcut2.html

Only problem is that it is for SuperCollider. Does anyone know

I have just recently discovered BBCut, which does algorithmic 
beat cutting and rythmic pattern genertion. Pretty cool stuff, 
check it out... http://www.cus.cam.ac.uk/~nc272/bbcut2.html
Only problem is that it is for SuperCollider. Does anyone know
there is a port of this to MAX?

bbcut-for-max

I'm building something in Max/MSP that does very similar stuff to 

this, though more along the lines of dblue's Glitch - more control in 

That said, I'd be very interested if anyone has ported Nick Collin's 

At 11:48 AM -0500 7/26/06, apalomba@austin.rr.com wrote:

>I have just recently discovered BBCut, which does algorithmic

>beat cutting and rythmic pattern genertion. Pretty cool stuff,

>Only problem is that it is for SuperCollider. Does anyone know

202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X

I'm building something in Max/MSP that does very similar stuff to 
this, though more along the lines of dblue's Glitch - more control in 
the user's hands.

That said, I'd be very interested if anyone has ported Nick Collin's 
PD work to Max...

At 11:48 AM -0500 7/26/06, apalomba@austin.rr.com wrote:
>I have just recently discovered BBCut, which does algorithmic
>beat cutting and rythmic pattern genertion. Pretty cool stuff,
>check it out... http://www.cus.cam.ac.uk/~nc272/bbcut2.html
>Only problem is that it is for SuperCollider. Does anyone know
>there is a port of this to MAX?
>
>
>
>Anthony
>

-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
http://www.defectiverecords.com
http://www.jackosx.com


I would be very interested in knowing more about the stuff

you are working on. One of the things I think is so cool 

about BBCut is its ability to use various algorithms to create 

crazy rhythmic patterns. What are your thoughts on finding

a balance between control and alg. generation? What mechanisms

I am not familiar with Nick Collin's PD work, what exactly 

I would be very interested in knowing more about the stuff
you are working on. One of the things I think is so cool 
about BBCut is its ability to use various algorithms to create 
crazy rhythmic patterns. What are your thoughts on finding
a balance between control and alg. generation? What mechanisms
do you employ? 

I am not familiar with Nick Collin's PD work, what exactly 
did it do?

http://mdsp.smartelectronix.com/2005/07/livecut.php

My work isn't algorithm-based at all, like BBCut (and LiveCut). As I 

that it has a series of effects, which you can control parameters on, 

and invoke at specific points in your audio input.

I mistyped about PD and Nick Collins - meant to say SuperCollider!

My work isn't algorithm-based at all, like BBCut (and LiveCut).  As I 
mentioned, it's more like Glitch (http://illformed.org/glitch), in 
that it has a series of effects, which you can control parameters on, 
and invoke at specific points in your audio input.

I see, Livecut is based on BBCut the BreakBeat Cutting library written 

by Nick Collins for SuperCollider. It looks like Livecut is a VST 

which means I can start experimenting with it in Max right now. It 

would be nice to have source to BBCut to port to Max. 

I see, Livecut is based on BBCut the BreakBeat Cutting library written 
by Nick Collins for SuperCollider. It looks like Livecut is a VST 
plugin,
which means I can start experimenting with it in Max right now. It 
would be nice to have source to BBCut to port to Max. 
Perhaps Nick is on this email list?

----- Original Message -----
From: Gideon Kiers 
Date: Wednesday, July 26, 2006 2:01 pm
Subject: Re: [maxmsp] BBCut for MAX?

> http://mdsp.smartelectronix.com/2005/07/livecut.php
>
> On 26-jul-2006, at 20:00, jln wrote:
>
> > LiveCut
>
>


The source to BBCut is fully available on his site.

At 2:12 PM -0500 7/26/06, apalomba@austin.rr.com wrote:

>I see, Livecut is based on BBCut the BreakBeat Cutting library written

>by Nick Collins for SuperCollider. It looks like Livecut is a VST

>which means I can start experimenting with it in Max right now. It

>would be nice to have source to BBCut to port to Max.

At 2:12 PM -0500 7/26/06, apalomba@austin.rr.com wrote:
>I see, Livecut is based on BBCut the BreakBeat Cutting library written
>by Nick Collins for SuperCollider. It looks like Livecut is a VST
>plugin,
>which means I can start experimenting with it in Max right now. It
>would be nice to have source to BBCut to port to Max.
>Perhaps Nick is on this email list?
>
>
>
>Anthony
>
>
>
>
>
>----- Original Message -----
>From: Gideon Kiers 
>Date: Wednesday, July 26, 2006 2:01 pm
>Subject: Re: [maxmsp] BBCut for MAX?
>
>>  http://mdsp.smartelectronix.com/2005/07/livecut.php
>>
>>  On 26-jul-2006, at 20:00, jln wrote:
>>
>>  > LiveCut
>>
>>

I looked at the available source, they are all suppercollider

files. Which appear to be some type of pseudo c-like language.

Is this what one would be porting to max? I was expecting there

I looked at the available source, they are all suppercollider
files. Which appear to be some type of pseudo c-like language.
Is this what one would be porting to max? I was expecting there
to be actual source code. 

At 2:31 PM -0500 7/26/06, apalomba@austin.rr.com wrote:

>I looked at the available source, they are all suppercollider

>files. Which appear to be some type of pseudo c-like language.

>Is this what one would be porting to max? I was expecting there

Well, it *is* source code, just SuperCollider source, rather than C 

At any rate, the thought I had was that someone knowledgeable in 

SuperCollider could read and interpret the SC source, and then 

translate that knowledge into a Max/MSP patch. I don't think it 

would require any new Max externals to be coded, at least that's not 

the sense I got when looking over the code myself a while back...

At 2:31 PM -0500 7/26/06, apalomba@austin.rr.com wrote:
>I looked at the available source, they are all suppercollider
>files. Which appear to be some type of pseudo c-like language.
>Is this what one would be porting to max? I was expecting there
>to be actual source code.
>
>Anthony

Well, it *is* source code, just SuperCollider source, rather than C 
or something....

At any rate, the thought I had was that someone knowledgeable in 
SuperCollider could read and interpret the SC source, and then 
translate that knowledge into a Max/MSP patch.  I don't think it 
would require any new Max externals to be coded, at least that's not 
the sense I got when looking over the code myself a while back...

I see, having someone with SC knowledge would be

very helpful then. I am pretty busy these days and 

do not have the time to learn SuperCollider.

I see, having someone with SC knowledge would be
very helpful then. I am pretty busy these days and 
do not have the time to learn SuperCollider.

I think the problem is that Livecut depends on VST time info to be 

provided to it, which unfortunately vst~ does not support.

It is surely among the most frequently brought up feature request of Max/MSP!

I think the problem is that Livecut depends on VST time info to be 
provided to it, which unfortunately vst~ does not support.

Man, I hope Cycling fixes vst~ sometime soon.

Man, I hope Cycling fixes vst~ sometime soon.
That is a pretty important feature!

I don't think vst~ is "broken"..... well maybe it is, I don't know. I have problems opening a lot of plugins that work "fine" in Cubase or what not, but I sort of suspect that Cubase compensates for poorly programmed plugins where Max does not.

Max is not a sequencer and currently there aren't any objects that output vst time info. I guess I could imagine an additional inlet on the vst~ where you could emulate the format using a variety of time objects.

Hey, when quoting other people try to keep it from maybe like one post instead of quoting the whole thread........................................damn it.

Max is not a sequencer and currently there aren't any objects that output vst time info.  I guess I could imagine an additional inlet on the vst~ where you could emulate the format using a variety of time objects.

Quote: Anthony Palomba wrote on Thu, 27 July 2006 16:41

----------------------------------------------------

> Man, I hope Cycling fixes vst~ sometime soon.

Yes Indeed !, we are all waiting for this.... good news is that Cycling promised it in my previous thread VST~ prayer....

Quote: Anthony Palomba wrote on Thu, 27 July 2006 16:41
----------------------------------------------------
> Man, I hope Cycling fixes vst~ sometime soon.
> That is a pretty important feature!

Yes Indeed !, we are all waiting for this.... good news is that Cycling promised it in my previous thread VST~ prayer....


Maybe I'm being nitpicky, but how does not having vst time info sent to the plugin make it broken? It's not in a sequencer environment so naturally it shouldn't have those variables present.....

Just seems like its unfair to call something broken when it's really not the case. Now, the graphical abnormalities with the vst object [and the scheduler problems they cause] may be an issue if the max scheduler is responsible for a part of the plugins audio aspects... That could be called broken, but still, I feel its more a case of difference in construction in how the vst specification makes directdraw or quicktime or whatever calls and that interfering with the max core which needs to place graphical issues in some sort of priority structure in order to preserve the scheduler..... In a program like Cubase I think they're on the same page as to how a vst should be inserted and related to the whole, where as the flexibility that max offers may have not been anticipated when steinberg set out to to do their thing [or whomever]...

I know theres been a lot of topics on max and graphics and graphical updates interfereing with the scheduler and then of course theres overdrive which preserves audio elements but still, it *seems* that doesn't influence any additional stability on the max side of things. I must admit it would be nice to not have to take that into account. Right now I generally have a computer running behind an interface computer in order to maintain the schedulers accuracy in leu of graphical updates.

If you use tracktion ever, theres apart in the preferences dialog that makes a mention of graphical abnormalities in relation to poorly programmed vst interfaces. I personally have tested every vst plugin in my library inside of max and only about 50% of them work very well. I have the list of plugins that work fine in Cubase [or take backseat priority in order to make it appear that's the case]... I'll probably start another thread about it tonight...

Maybe I'm being nitpicky, but how does not having vst time info sent to the plugin make it broken?  It's not in a sequencer environment so naturally it shouldn't have those variables present..... 

Just seems like its unfair to call something broken when it's really not the case. Now, the graphical abnormalities with the vst object [and the scheduler problems they cause] may be an issue if the max scheduler is responsible for a part of the plugins audio aspects...   That could be called broken, but still, I feel its more a case of difference in construction in how the vst specification makes directdraw or quicktime or whatever calls and that interfering with the max core which needs to place graphical issues in some sort of priority structure in order to preserve the scheduler..... In a program like Cubase I think they're on the same page as to how a vst should be inserted and related to the whole, where as the flexibility that max offers may have not been anticipated when steinberg set out to to do their thing [or whomever]...

I know theres been a lot of topics on max and graphics and graphical updates interfereing with the scheduler and then of course theres overdrive which preserves audio elements but still, it *seems* that doesn't influence any additional stability on the max side of things.  I must admit it would be nice to not have to take that into account.  Right now I generally have a computer running behind an interface computer in order to maintain the schedulers accuracy in leu of graphical updates.

If you use tracktion ever, theres apart in the preferences dialog that makes a mention of graphical abnormalities in relation to poorly programmed vst interfaces.  I personally have tested every vst plugin in my library inside of max and only about 50% of them work very well. I have the list of plugins that work fine in Cubase [or take backseat priority in order to make it appear that's the case]... I'll probably start another thread about it tonight...


Transport control is part of the VST~ api. Cycling 

decided to not fully implement this api, for whatever

reason. I guess the better word to use would be "incomplete" 

> Maybe I'm being nitpicky, but how does not having vst time info 

> sent to the plugin make it broken? It's not in a sequencer 

> environment so naturally it shouldn't have those variables 

> Just seems like its unfair to call something broken when it's 

> really not the case. Now, the graphical abnormalities with the vst 

> object [and the scheduler problems they cause] may be an issue if 

> the max scheduler is responsible for a part of the plugins audio 

> aspects... That could be called broken, but still, I feel its 

> more a case of difference in construction in how the vst 

> specification makes directdraw or quicktime or whatever calls and 

> that interfering with the max core which needs to place graphical 

> issues in some sort of priority structure in order to preserve the 

> scheduler..... In a program like Cubase I think they're on the 

> same page as to how a vst should be inserted and related to the 

> whole, where as the flexibility that max offers may have not been 

> anticipated when steinberg set out to to do their thing [or 

> I know theres been a lot of topics on max and graphics and 

> graphical updates interfereing with the scheduler and then of 

> course theres overdrive which preserves audio elements but still, 

> it *seems* that doesn't influence any additional stability on the 

> max side of things. I must admit it would be nice to not have to 

> take that into account. Right now I generally have a computer 

> running behind an interface computer in order to maintain the 

> schedulers accuracy in leu of graphical updates.

> If you use tracktion ever, theres apart in the preferences dialog 

> that makes a mention of graphical abnormalities in relation to 

> poorly programmed vst interfaces. I personally have tested every 

> vst plugin in my library inside of max and only about 50% of them 

> work very well. I have the list of plugins that work fine in 

> Cubase [or take backseat priority in order to make it appear 

> that's the case]... I'll probably start another thread about it 

Transport control is part of the VST~ api. Cycling 
decided to not fully implement this api, for whatever
reason. I guess the better word to use would be "incomplete" 
rather than "broken". 

----- Original Message -----
From: binez0r 
Date: Monday, July 31, 2006 5:08 am
Subject: [maxmsp] Re:  BBCut for MAX?

>
> Maybe I'm being nitpicky, but how does not having vst time info 
> sent to the plugin make it broken?  It's not in a sequencer 
> environment so naturally it shouldn't have those variables 
> present..... 
>
> Just seems like its unfair to call something broken when it's 
> really not the case. Now, the graphical abnormalities with the vst 
> object [and the scheduler problems they cause] may be an issue if 
> the max scheduler is responsible for a part of the plugins audio 
> aspects...   That could be called broken, but still, I feel its 
> more a case of difference in construction in how the vst 
> specification makes directdraw or quicktime or whatever calls and 
> that interfering with the max core which needs to place graphical 
> issues in some sort of priority structure in order to preserve the 
> scheduler..... In a program like Cubase I think they're on the 
> same page as to how a vst should be inserted and related to the 
> whole, where as the flexibility that max offers may have not been 
> anticipated when steinberg set out to to do their thing [or 
> whomever]...
> I know theres been a lot of topics on max and graphics and 
> graphical updates interfereing with the scheduler and then of 
> course theres overdrive which preserves audio elements but still, 
> it *seems* that doesn't influence any additional stability on the 
> max side of things.  I must admit it would be nice to not have to 
> take that into account.  Right now I generally have a computer 
> running behind an interface computer in order to maintain the 
> schedulers accuracy in leu of graphical updates.
>
> If you use tracktion ever, theres apart in the preferences dialog 
> that makes a mention of graphical abnormalities in relation to 
> poorly programmed vst interfaces.  I personally have tested every 
> vst plugin in my library inside of max and only about 50% of them 
> work very well. I have the list of plugins that work fine in 
> Cubase [or take backseat priority in order to make it appear 
> that's the case]... I'll probably start another thread about it 
>


> Maybe I'm being nitpicky, but how does not having vst time info sent to the plugin make it broken?

Other responses aside, I don't understand why you feel the need to argue 

against the many requests to provide this functionality. Clearly it 

binez0r wrote:
> Maybe I'm being nitpicky, but how does not having vst time info sent to the plugin make it broken?

Other responses aside, I don't understand why you feel the need to argue 
against the many requests to provide this functionality.  Clearly it 
would make lives easier/better.


Now this is an old thread, I hope I can still ask anyway, has anyone done something similar for Max especially Max for Live since 2006. Would really be nice to have a tool like this in Max for Live, something in direction live cut, which is a very cool plugin I must say.

After a bit of browsing I do start to find a lot of adaptations and other things people have made since, inspired by BBCut it seems.

Still would be nice to know more on this topic. :D