wippen

I traded some messages about looping strategies a couple of weeks back with some members. Today I finally got around to cleaning up a looping patch I use so I could post it. You can download it at:

This looper records loops with dynamic lengths; the length of time you hold down the record button is the length of the loop. All loops which are recorded after that are automatically given lengths which are subdivisions of the first loop or multiples of those subdivisions, so that all remain quantized and synchronized, but there is the freedom to create loops which are shorter or longer than the first.

The patcher is not designed as a stand-alone, use it for everything program, but I cleaned it up enough so that it should be easy to implement into any project.

I traded some messages about looping strategies a couple of weeks back with some members.  Today I finally got around to cleaning up a looping patch I use so I could post it.  You can download it at:

This looper records loops with dynamic lengths; the length of time you hold down the record button is the length of the loop.  All loops which are recorded after that are automatically given lengths which are subdivisions of the first loop or multiples of those subdivisions, so that all remain quantized and synchronized, but there is the freedom to create loops which are shorter or longer than the first.

dynamic-looper

thanks a lot fro the sharing,cool patch, the others too btw.

but it would be great if everybody's shared patches were a bit cleaner,

*shoots off to clean up his own snake hole mess*

but it would be great if everybody's shared patches were a bit cleaner,
code reuse is a tricky thing.

I just uploaded a version of this looper encapsulated in a subpatcher. There are only two buttons to push; should be easy enough for anyone to use now.

Also fixed a bug in the loop-length tolerance.

A while back, I was designing all of my code to be "standardized" for my own purposes, so that I wouldn't end up with new versions of the same subpatches each time I did a project. After all, this is the whole precept of OOP, why shouldn't it work in Max/MSP? I quickly found, however, that many subpatches desperately needed to be individually tailored to the task at hand, and attempts to make the basic, standardized patches work in all situations ended up in subpatches with excessive numbers of parameter-settings. Another issue is presets; I could not find a reliable means of saving presets in patchers which were loaded as subpatchers.

For these reasons, I went back to using [p subpatcher] subpatchers, and making them fit the rest of the program internally.

Due to these methods of working, I find it easiest to structure a large program, such as this looper, into two main parts: a subpatch which has a limited amount of inputs which can be put in the pricipal window of a performance-patch and connected easily with the rest of the subpatches (as I have done with the present download) and a pop-up control-panel with as much of the parameters and functional controls as possible. What happens inside of the subpatch can be structured as it comes; my deadlines have to do with performances and premiers, not with the creation of visually pleasing object-routing.

I just uploaded a version of this looper encapsulated in a subpatcher.  There are only two buttons to push; should be easy enough for anyone to use now.
Also fixed a bug in the loop-length tolerance.

Reuseable code...
A while back, I was designing all of my code to be "standardized" for my own purposes, so that I wouldn't end up with new versions of the same subpatches each time I did a project.  After all, this is the whole precept of OOP, why shouldn't it work in Max/MSP?  I quickly found, however, that many subpatches desperately needed to be individually tailored to the task at hand, and attempts to make the basic, standardized patches work in all situations ended up in subpatches with excessive numbers of parameter-settings.  Another issue is presets; I could not find a reliable means of saving presets in patchers which were loaded as subpatchers.
For these reasons, I went back to using [p subpatcher] subpatchers, and making them fit the rest of the program internally.

Due to these methods of working, I find it easiest to structure a large program, such as this looper, into two main parts: a subpatch which has a limited amount of inputs which can be put in the pricipal window of a performance-patch and connected easily with the rest of the subpatches (as I have done with the present download) and a pop-up control-panel with as much of the parameters and functional controls as possible.  What happens inside of the subpatch can be structured as it comes; my deadlines have to do with performances and premiers, not with the creation of visually pleasing object-routing.


>my deadlines have to do with performances and premiers, not with the creation of visually pleasing object-routing.

that you have a patching style that suits your purposes and deadlines is totally fine , i feel though when you start sharing patches with others it is not a matter of making a patch "visually pleasing " but just readable so that the intelligence/creativity of your patch is quickly grasped by anybody else.

Most people on this list make a certain effort to share clear and well organised patches which makes patches easy to use, transform, enabling the intrinseque evolution necessary for a community to grow .

i dont think that most people are interested in how a patch looks ( although design is a big part of patching ) but rather in how a patch works, the solutions you find out can be of use for many others only if these solutions are "accessible". 

A clean patch is also of great benefit for you as you will receive more feedback and usefull comments specially by more advanced members who would share their knowledge with you.

would you read a paper where half the punctuation is missing even though it seems interesting ?

besides that thanks for sharing and for your enthusiasm, i hope you will not feel offended by this post.

that you have a patching style that suits your purposes and deadlines is totally fine , i feel though when you start sharing patches with others it is not a matter of making a patch "visually pleasing " but just readable so that the intelligence/creativity of your patch is quickly grasped by anybody else.
Most people on this list make a certain effort to share clear and well organised patches which makes patches easy to use, transform, enabling the intrinseque evolution necessary for a community to grow  .
i dont think that most people are interested in how a patch looks ( although design is a big part of patching ) but rather in how a patch works, the solutions you find out can be of use for many others only if these solutions are "accessible". 
A clean patch is also of great benefit for you as you will receive more feedback and usefull comments specially by more advanced members who would share their knowledge with you.
 would you read a paper where half the punctuation is missing even though it seems interesting ?
besides that thanks for sharing and for your enthusiasm, i hope you will not feel offended by this post.


...not exactly offended, but one question: did you look at the patch?

Quote: Dayton wrote on Sun, 18 June 2006 09:27

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

> ...not exactly offended, but one question: did you look at the patch?

i don't know if he did, but i did and well...

i really feel ackward, because the patch seems nice and i love people sharing,but it really is a real pain reading it.

the comments help, but that's it, i'd need to restructure it entirely to really fully comprehend, which is ncessary for me to use a patch.

Quote: Dayton wrote on Sun, 18 June 2006 09:27
----------------------------------------------------
> ...not exactly offended, but one question: did you look at the patch?
----------------------------------------------------

i don't know if he did, but i did and well...
i really feel ackward, because the patch seems nice and i love people sharing,but it really is a real pain reading it.
the comments help, but that's it, i'd need to restructure it entirely to really fully comprehend, which is ncessary for me to use a patch.

It is good that I get this feedback; it is what I was looking for; in order to communicate well, it is important to learn the standard of communication being used by a community, and I am learning. Because of this, I thank both of you for the comments!

In order to find out the general level of what is being traded here, I've looked at what I could find, and there seem to be two extremes: very nicely polished programs and very small solutions to problems. I assume, however, that a great many of us are creating patches between the two extremes, and these, for the reasons stated, do not get posted. The main difficulty is when the post is addressing a specific hurdle, but the larger program is necessary to put it into perspective.

Isjtar looked at the first version I uploaded, and I realized after that that it would be easier to get immediate results if I put the subpatch on the web instead of the guts. I appreciate his perseverance in trying to understand what I was getting at.

If there are more comments and criticism, fire away; positively so if it is possible!

It is good that I get this feedback; it is what I was looking for; in order to communicate well, it is important to learn the standard of communication being used by a community, and I am learning.  Because of this, I thank both of you for the comments!

In order to find out the general level of what is being traded here, I've looked at what I could find, and there seem to be two extremes: very nicely polished programs and very small solutions to problems.  I assume, however, that a great many of us are creating patches between the two extremes, and these, for the reasons stated, do not get posted.  The main difficulty is when the post is addressing a specific hurdle, but the larger program is necessary to put it into perspective.

Isjtar looked at the first version I uploaded, and I realized after that that it would be easier to get immediate results if I put the subpatch on the web instead of the guts.  I appreciate his perseverance in trying to understand what I was getting at.

If there are more comments and criticism, fire away; positively so if it is possible!


yes i did actually , and more specifically at the subpatch ( which is all your "engine" and which a little "messy" :), unless i downloaded something wrong ).

i would not comment on something i would not see...

yes i did actually , and more specifically at the subpatch ( which is all your "engine"  and which a little "messy" :), unless i downloaded something wrong ).
i would not comment on something i would not see...


i was very interested by your patch (the title of the topic is in my 

area of research nowerdays, and it's always a good idea to look at 

others patches), but i 've quit reading it 1,5 second after opening it, 

and didn't kept a trace of on my hd because of the layout... Everybody 

has its own way to max, but i wonder how you can work with it, really, 

or structure your thoughts this way... I myself have ugly pieces of code 

(especially bad written Java), and i try to do my best to not let 

anybody take an eye on before i clean it. When i don't, i have to 

re-write all a few months later... Anyway, does your kitchen look the 

As an advice (not from a so old maxer, indeed), layout is more than a 

part of the patching process. Way things are connected, fact there's a 

special process order in max (from right to left, according to position 

of objects on the white page) are very very important : to understand 

what you're doing, to make it simply more efficient, to be able to read 

it a few months later, to make it available / understandable by somebody 

There's one on the list who's making curly fancy connections (he knows 

i was very interested by your patch (the title of the topic is in my 
area of research nowerdays, and it's always a good idea to look at 
others patches), but i 've quit reading it 1,5 second after opening it, 
and didn't kept a trace of on my hd because of the layout... Everybody 
has its own way to max, but i wonder how you can work with it, really, 
or structure your thoughts this way... I myself have ugly pieces of code 
(especially bad written Java), and i try to do my best to not let 
anybody take an eye on before i clean it. When i don't, i have to 
re-write all a few months later... Anyway, does your kitchen look the 
same :-)

As an advice (not from a so old maxer, indeed), layout is more than a 
part of the patching process. Way things are connected, fact there's a 
special process order in max (from right to left, according to position 
of objects on the white page) are very very important : to understand 
what you're doing, to make it simply more efficient, to be able to read 
it a few months later, to make it available / understandable by somebody 
else, etc...

There's one on the list who's making curly fancy connections (he knows 
who he is) but it's still readable ;-)

Dynamic Looper