Talking 'bout tightness
As a musician one would like a sound system to be tight, as in sample TIGHT.
For instance, if i go ahead an recorded, say my little max/msp drummacine output, i would expect it to be TIGHT, if the samples were played with the same interval in samples over and over again. Noting less!
Now that i am beginning to design my system, I don't really know whether I'll face a problem or not.
But I see people talking bout the metro object not being tight. Is that really true?
What tightness-issues should i keep in mind when designing my system?
Should i do a lot of prep work with buffers, or should i just trigger playing/recording based on metro or alike.
--
I am trynig to build a audio loop system of audio buffers for sync recording and loop playback.
Theese can have diffent lenghts but cannot "slide" out of synch with each other. Also a simple drum machine is running, playing oneshot samples.
I can't give you all the answers, but can relate specific experience:
I work with my own loop-player which is based on [stutter] objects, which are basically two buffers configured to work together. The first buffer acts as a constant record of what has been played (or not played) during the last x miliseconds. The second can be told to grab a part of the first buffer and repeat it. The playback speed and position is controlled by a [phasor] object, as is common for [stutter]. This constantly goes from 0 to 1. Now, the (samplerate / number of samples)*playbackspeed (where 1. is normal playbackspeed) will cause the [phasor] to complete its ramp in the same number of samples as the playback buffer.
Since I needed to sync the playback with other routines, including MIDI, I needed a bang at the beginning of the cycle. I did this by connecting two objects to the output of the [phasor]: ->[>=~ 0.98]->[edge~]
There may be another way, but since this works fine for me, I didn't look any further (yet). I also set the Max scheduler to audio interrupt (DSP Status).
All of the [stutter] objects have their own [phasor] objects, but the frequency of each is quantized beforehand in relation to the first frequency. For instance, if I record the first "master" loop and it turns out to be almost one second long, but not quite (let's say 44099 samples) but I have my quantization set to allow half-notes, then the first loop is bumped up to a rounded-off value of half of the number of samples (round(44099/2))*2. This assures synchronized lengths. Even if the beginning of the [phasor] cycle is off by a few samples, you won't hear it, and this displacement will remain constant.
I have never needed to use more than six audio loops at a time, and I commonly use the looping function for no more than two or three minutes before starting new loops, usually not more than one minute, so I cannot empirically say that it is perfectly in sync. The few times that I have left it looping for ten minutes and more, however, it was still in sync. Also, using it with Jitter-loops in real-time performance processing, it has stayed in sync with itself, MIDI and the frame-rate of the video for five or six minutes at a time during all performances and rehearsals.
Max is perfectly capable of playing loops very tightly synced.
But in some cases you have to be aware of a few in-depth technical 'details' about how max works internally. The whole metro issue is about knowing what you're doing. I am afraid to really know what you're doing you'll have to read this carefully:
I'd say, first try to make your setup based on what you know from the tutorials and manuals, 90% chance that you'll succeed. If you get sync problems read the article and then post your patch on this forum so that ppl can point you in the right direction.
Good luck,
Mattijs
Quote: McSkelle wrote on Wed, 07 March 2007 09:55
----------------------------------------------------
> As a musician one would like a sound system to be tight, as in sample TIGHT.
> For instance, if i go ahead an recorded, say my little max/msp drummacine output, i would expect it to be TIGHT, if the samples were played with the same interval in samples over and over again. Noting less!
>
> Now that i am beginning to design my system, I don't really know whether I'll face a problem or not.
>
> But I see people talking bout the metro object not being tight. Is that really true?
>
> What tightness-issues should i keep in mind when designing my system?
> Should i do a lot of prep work with buffers, or should i just trigger playing/recording based on metro or alike.
>
> --
>
> I am trynig to build a audio loop system of audio buffers for sync recording and loop playback.
> Theese can have diffent lenghts but cannot "slide" out of synch with each other. Also a simple drum machine is running, playing oneshot samples.
>
----------------------------------------------------
its all right what Mattijs said but i want to add something
which looks like the opposite to it.
if you use metro, you are using a message system.
2 messages (bang) coming out of metro, connected to 2
somethings, will NEVER arrive at their aims at the same time.
2 samples (for example an "1." sample, a click),
will ALWAYS arrive at the same time when connected to 2
aims. (or to be exact, _within the same sample)
so the more time accuracy you want, the more you should try
to build everything in DSP.
messages might be faster (1 sample lasts 1/44100 second) but
messages are impossible to sync to each other.
there are 2 problems with using only signals:
• DSP significantly uses more CPU than messages (if the data
amount to be transferred is low, like using signal clicks as
metro replacement)
• there are quite a few audio objects which simply do
not take signals; you cant start sfplay~ using a signal
for example.
now have some coffee, look at your objects library again,
and choose wisely.
:)
-110
Looking back at my archives I found this test, which is just a visualisation of what R. T. just wrote. Try changing the on/off settings for overdrive and audio interrupt scheduler while using it.
>
>But I see people talking bout the metro object not being tight. Is
>that really true?
>
it is SO true.......
that i came to think it is a running gag at C74 office... "hey,
let's make the metro even sloppier!!!!"
(yes i know the usual answers are about us, users, not understanding
what the OS does - and this is true, i don't - but all
sequencers/apps I know have a working metro-like tightness... well,
ok....)
best
kasper
Quote: Kasper T Toeplitz wrote on Wed, 07 March 2007 12:01
----------------------------------------------------
> >
> >But I see people talking bout the metro object not being tight. Is
> >that really true?
> >
>
>
> it is SO true.......
>
> that i came to think it is a running gag at C74 office... "hey,
> let's make the metro even sloppier!!!!"
I really wouldn't say these kind of things if you're obviously not a dsp/multithreading programmer.. Your remarks should be aimed towards the documentation or the learning curve, not the application.
>
> (yes i know the usual answers are about us, users, not understanding
> what the OS does - and this is true, i don't - but all
> sequencers/apps I know have a working metro-like tightness... well,
> ok....)
I agree with you about this. Users shouldn't be blamed that they don't understand. I think cycling is obliged to
a) add a chapter to the max fundamentals that explains exactly how to use metro (and threading) and how not to, with overly clear examples,
-or-
b) open the description of max with "max is a graphic programming language with a huge standard library for event handling, audio processing and communication with hardware". System requirements: "a bachelors degree in technical engineering or a lot of luck".
Mattijs
If we could bundle this test with a few others, together with clear and simple clarifications and finally notes and examples how to approach possible issues in the correct way, we'd have a real solution for the everlasting 'metro' misunderstanding.
Mattijs
Quote: Dayton wrote on Wed, 07 March 2007 11:58
----------------------------------------------------
> Looking back at my archives I found this test, which is just a visualisation of what R. T. just wrote. Try changing the on/off settings for overdrive and audio interrupt scheduler while using it.
>
> max v2;
> #N vpatcher 15 55 615 524;
> #P window setfont "Sans Serif" 10.;
> #P flonum 327 292 95 10 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P window linecount 1;
> #P newex 327 254 32 9109514 timer;
> #P message 272 95 17 9109514 0.;
> #P button 272 71 15 0;
> #P button 253 210 15 0;
> #P button 225 210 15 0;
> #P newex 225 180 38 9109514 edge~;
> #P newex 225 148 57 9109514 >=~ 0.58;
> #P newex 225 118 57 9109514 phasor~ 1.;
> #P user number~ 150 373 236 389 10 139 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 150 337 27 9109514 -~;
> #P flonum 119 290 95 10 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 119 252 32 9109514 timer;
> #P message 113 95 17 9109514 0.;
> #P button 113 71 15 0;
> #P toggle 156 30 15 0;
> #P newex 405 117 62 9109514 metro 1000;
> #P button 94 210 15 0;
> #P button 66 210 15 0;
> #P newex 66 180 38 9109514 edge~;
> #P newex 66 148 44 9109514 >=~ 0.58;
> #P newex 66 118 57 9109514 phasor~ 1.;
> #P user ezdac~ 18 43 62 76 0;
> #P window linecount 3;
> #P comment 177 242 100 9109514 ms difference between bang outputs from [edge];
> #P window linecount 4;
> #P comment 362 236 100 9109514 ms difference between bang output from [edge] and [metro];
> #P window linecount 2;
> #P comment 182 338 100 9109514 actual difference between signals;
> #P connect 4 0 5 0;
> #P connect 5 0 6 0;
> #P connect 6 0 7 0;
> #P connect 6 1 8 0;
> #P fasten 10 0 11 0 161 55 118 55;
> #P connect 11 0 12 0;
> #P connect 12 0 4 1;
> #P fasten 8 0 13 0 99 234 124 234;
> #P connect 13 0 14 0;
> #P fasten 21 0 13 1 258 233 146 233;
> #P fasten 4 0 15 0 71 143 47 143 47 317 155 317;
> #P connect 15 0 16 0;
> #P fasten 17 0 15 1 230 143 172 143;
> #P connect 17 0 18 0;
> #P connect 18 0 19 0;
> #P connect 19 0 20 0;
> #P connect 19 1 21 0;
> #P fasten 10 0 22 0 161 55 277 55;
> #P connect 22 0 23 0;
> #P connect 23 0 17 1;
> #P fasten 21 0 24 0 258 233 332 233;
> #P connect 24 0 25 0;
> #P fasten 9 0 24 1 410 232 354 232;
> #P fasten 10 0 9 0 161 55 410 55;
> #P pop;
>
----------------------------------------------------
>Quote: Kasper T Toeplitz wrote on Wed, 07 March 2007 12:01
>----------------------------------------------------
>> >
>> >But I see people talking bout the metro object not being tight. Is
>> >that really true?
>> >
>>
>>
>> it is SO true.......
>>
>> that i came to think it is a running gag at C74 office... "hey,
>> let's make the metro even sloppier!!!!"
>
>I really wouldn't say these kind of things if you're obviously not a
>dsp/multithreading programmer.. Your remarks should be aimed towards
>the documentation or the learning curve, not the application.
>
ok
it was a joke see. like in ;-)
i really think it i s _funny_ that maxmsp - a brillant program that i
use almost daily - does not have a tight "metro".
I don't blame the learning curve, the doc or wahtever
if you read what metro i supposed to do, and then you create a [metro
1000] object you expect it to bang every second, right?? kind like
when i look at the time counter in ProTools, when it says my music is
played since XX:xx time, i kind of trust it. I mean it says so and i
belive it is true.
when i ask a metro to bang every second, i - now - know it bangs when
it can which is very often evey 1000-1300 miliseconds
i might be wrong, but i never read anywhere in the metro's doc that
if you want to output a bang every xx miliseconds you shoul NOT use
metro but go into the audio (msp) domain.
not being a dsp/multithreading programmer does not change much
here.... i just expected the objects to work as explained. Took me
time to understand it is not the case (i never trust a time counter
based on matro anymore...)
best
kasper
--
Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com
Wauuu...a lot of tough reading for me to do here.
I'm not sure i understand the "domain" discussion.
If i make a groove object to loop every second, would i then have made a DSP domain metro running 60 bpm?
I'm eager to move on and try the above sample code. Thanks :-) !
Any looper/overdub/sound-on-sound pathers would be greatly appriciated. I AM a beginner with max/msp.
On the other hand i am a muscician - not trying to be a programmer at all. I play with computers all right, but really I feel I shoud play my guitar instead;-)
I think the max'er community is ready to be used by "classic" muscician types like my self. Not a dj, not a coding laptop artist, just a guy playing what have you, but wanting too "team up" with some tech to reach greater ground.
thanks again all - i'm still reading your posts to understand things better:-)
Quote: McSkelle wrote on Wed, 07 March 2007 05:20
> If i make a groove object to loop every second, would i then have made a DSP domain metro running 60 bpm?
actually no... if you start the groove at the same time as any other groove, it will stay in sync. I put a "resync" button which uses the [edge] technique above to resync all phasors at once, but I never had to use it (it comes in handy if I am making music with loops which have varying lengths, however.) It is useful with MIDI and video. MIDI needs to be fairly synchronized (within its own latency-jitter), but video is a bit more forgiving.
> I think the max'er community is ready to be used by "classic" muscician types like my self. Not a dj, not a coding laptop artist, just a guy playing what have you, but wanting too "team up" with some tech to reach greater ground.
>
Definitely. I program, but am and always was a musician first and formost. Programming is never an end in and of itself; it is always at the service of some specific work to be done. Still, as was pointed out to me a while ago, this forum is dedicated almost exclusively at the technical aspects of art and needs to be so in order to be effective.
Quote: Dayton wrote on Wed, 07 March 2007 13:45
----------------------------------------------------
> Quote: McSkelle wrote on Wed, 07 March 2007 05:20
>
> > If i make a groove object to loop every second, would i then have made a DSP domain metro running 60 bpm?
>
> actually no... if you start the groove at the same time as any other groove, it will stay in sync. I put a "resync" button which uses the [edge] technique above to resync all phasors at once, but I never had to use it (it comes in handy if I am making music with loops which have varying lengths, however.) It is useful with MIDI and video. MIDI needs to be fairly synchronized (within its own latency-jitter), but video is a bit more forgiving.
The correct answer is that if you want to have different loops play in sync, drive them all with one phasor. I can imagine that to do this, groove~ is less suitable than for instance play~.
>
> > I think the max'er community is ready to be used by "classic" muscician types like my self. Not a dj, not a coding laptop artist, just a guy playing what have you, but wanting too "team up" with some tech to reach greater ground.
> >
>
>
> Definitely. I program, but am and always was a musician first and formost. Programming is never an end in and of itself; it is always at the service of some specific work to be done. Still, as was pointed out to me a while ago, this forum is dedicated almost exclusively at the technical aspects of art and needs to be so in order to be effective.
>
----------------------------------------------------
one should never exspect a [metro 1000] to output a
bang every 1000.000000000000000 milliseconds.
but what makes some of us rather sad is that you can
sometimes, even with overdrive on, not produce musically
usable 1/32. or 1/64 notes with it.
and phasor~ ... how many posts have there been this month
abolut how to reset phasors phase ? :)
>one should never exspect a [metro 1000] to output a
>bang every 1000.000000000000000 milliseconds.
>
oh, if it would stay in a 1000 - 1010 range i would be happy!!!
with working patches (audio ok, no cliks etc) i am more often in the
1000-1300 range!
kasper
--
Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com
Quote: Mattijs wrote on Wed, 07 March 2007 06:26
----------------------------------------------------
> The correct answer is that if you want to have different loops play in sync, drive them all with one phasor. I can imagine that to do this, groove~ is less suitable than for instance play~.
----------------------------------------------------
Yes, but that would preclude any possibility of pitch-bending and/or phase-shifting the individual loops, which is one of the reasons I got into Max/MSP in the first place.
My abstraction wish-list for the looping patch tried to include all forseeable musical situations. I'm sure it didn't, but I try. Usually, half of the stuff in my patches end up in the catagory "I don't need this now, but I might someday..."
On 7 mars 07, at 15:03, Kasper T Toeplitz wrote:
>> one should never exspect a [metro 1000] to output a
>> bang every 1000.000000000000000 milliseconds.
>
> with working patches (audio ok, no cliks etc) i am more often in the
> 1000-1300 range!
Now I understrand why your pieces are sooo long ;-)
_____________________________
Patrick Delges
Centre de Recherches et de Formation Musicales de Wallonie asbl
http://users.skynet.be/crfmw/max
Quote: Dayton wrote on Wed, 07 March 2007 15:07
----------------------------------------------------
> Quote: Mattijs wrote on Wed, 07 March 2007 06:26
> ----------------------------------------------------
>
> > The correct answer is that if you want to have different loops play in sync, drive them all with one phasor. I can imagine that to do this, groove~ is less suitable than for instance play~.
>
> ----------------------------------------------------
>
> Yes, but that would preclude any possibility of pitch-bending and/or phase-shifting the individual loops, which is one of the reasons I got into Max/MSP in the first place.
Why?
Phase shifting:
Pitch bending:
Everything you want can be done without any syncing problems, believe me. You just need to know how. But as I agreed, the docs are inadequate in some cases if you don't have a technical background.
Mattijs
and another option is to look at eric lyon's (3rd party) sample accurate object "samm~" available here:
havent had time to test this thoroughly but it looks interesting!
j
Quote: Roman Thilenius wrote on Wed, 07 March 2007 14:38
----------------------------------------------------
>
>
> one should never exspect a [metro 1000] to output a
> bang every 1000.000000000000000 milliseconds.
>
> but what makes some of us rather sad is that you can
> sometimes, even with overdrive on, not produce musically
> usable 1/32. or 1/64 notes with it.
1/64 note at 120 bpm =~ 8 ms, a factor 0.25 off =~ 2 ms. That's very well possible considering that the scheduler event interval is 2 ms by default. But now we're entering the general making-music-with-computers discussion. I suppose a multithreaded OS will always have problems when we're in this time range, that's probably why the amiga trackers and cubase for atari are still famous for their tightness among trained listeners.
The only improvement I can imagine is that the high priority queue (= scheduler) always seems to serviced with a minimum interval. Perhaps cycling 74 could change this system so that it will be serviced as often as possible, with a maximum interval of 2 ms, as long as processor power permits. But to say anything sensible about that I would need a look at the source code and I don't think cycling would let me :'|
But all this is not about sync. Sync is still a matter of correct implementation.
>
>
> and phasor~ ... how many posts have there been this month
> abolut how to reset phasors phase ? :)
I missed those.. is there something wrong with a 0 in the right outlet?
Mattijs
Quoting Mattijs Kneppers :
> I agree with you about this. Users shouldn't be blamed that they
> don't understand. I think cycling is obliged to
>
> a) add a chapter to the max fundamentals that explains exactly
> how to use metro (and threading) and how not to, with overly
> clear examples,
Oh yeah, and not just metro. I've read through the docs, had it
repeatedly explained to me, but I still don't quite get the actual
effect that things like "overdrive" and "slop" and the latency
settings on windows, all combined with sigvec and i/o vec sizes
actually have. Some of it is nomenclature ("overdrive?" -- I never
even knew what that did for an automobile). Several of these
settings seem to interact, and I've noticed that the do so very
differently depending on whether you are using Windows or OSX.
PS -- related comment on the dev list to this...
Yep, el.samm~ and it's associated objects are well
worth checking out, if you're on a Mac.
I started converting an old drum machine patch that
had grown really sloppy, to use these objects instead
of regular scheduler stuff, and it improved things no
end.
You can't do everything in the signal domain, but
these objects are a great leap in that direction, and
even if you have to completely redesign the patch (as
i did), it's worth the effort if tightness is your
goal.
You'll find some info on samm in this thread (and some
other interesting thoughts on this subject too):
http://tinyurl.com/l49ch
cheers
Roger
On Mar 7, 2007, at 11:44 AM, ROGER CARRUTHERS wrote:
> Yep, el.samm~ and it's associated objects are well
> worth checking out, if you're on a Mac.
Amen to that. I said it before but it bears repeating: "If you had
seen Eric Lyon's paper at ICMC 2006 you would not be having this
conversation." Lucky for you it is online...
A Sample Accurate Triggering System for Pd and MaxMSP
http://www.sarc.qub.ac.uk/~elyon/LyonPapers/SampleAccurate-Lyon-
ICMC2006.pdf
-------------------
Nathan Wolek, PhD --- nwolek@stetson.edu
Assistant Professor of Music Technology
Stetson University - DeLand, FL
http://www.nathanwolek.com
> Quote: Dayton wrote on Wed, 07 March 2007 15:07
> ----------------------------------------------------
> Why?
> Phase shifting:
>
>
That threw me for a bit, so I tried it out. No go (although I don't rule out the possibility of my being extremely dense at the moment.) There are three problems to this approach:
1. Any real-time changes cause ugly clicks
2. I can't go backwards with one loop and forward with another
3. The numbers I feed to [/] or [+] do not give me an accurate representation about what I am doing to the sound (although a bit of dynamic scaling would).
Basically, I need to be able to do anything with the (in my case) [stutter] objects individually and collectively, and sync them back up on command.
I would love to use only one phasor for this patch, so I would be more than happy if you prove me wrong.
Here is the test-patch:
If you are going to do anything with signal rate timing, I highly
recommend looking into and fully understanding the following objects:
sync~
rate~
zigzag~
adsr~
pong~
edge~
>~,
index~
+=~
and of course clever use of buffer~.
Being able to use these objects with some finesse should allow you to
solve most problems that you will come up against with managing a
signal-based timing structure.
FWIW, I have not checked out Eric's objects, but most of the problems
given in his paper can be solved with some combination of the above objects.
Cheers,
Andrew B.
>> 1/64 note at 120 bpm =~ 8 ms, a factor 0.25 off =~ 2 ms.
>> That's very well possible considering that the scheduler
>> event interval is 2 ms by default.
a 64th is normally 31.25 or 62.5 ms long @ 120 bpm, depending
on how you count.
well or 8 - depending how you count! :)
but try this:
if there is anybody who can tell if those beats are straight
or punctuated he/she obviously know more about metro than
kasper and me. :) to me it sounds more like "random" than
like "sequencing".
(btw, according to your theory above those are half notes, LOL.)
> > and phasor~ ... how many posts have there been this month
> > abolut how to reset phasors phase ? :)
>
> I missed those.. is there something wrong with a 0 in the right outlet?
... it does not accept signals, so when you need to sync 35
phasors (which is why we want to reset phase) you have
a problem.
or was it cycle~ what i had in mind here?
> >> 1/64 note at 120 bpm =~ 8 ms, a factor 0.25 off =~ 2 ms.
> >> That's very well possible considering that the scheduler
> >> event interval is 2 ms by default.
>
>
> a 64th is normally 31.25 or 62.5 ms long @ 120 bpm, depending
> on how you count.
> well or 8 - depending how you count! :)
we are all a bit retarded i think.
i just noticed that on my "developer" computer i had the
signal vector size set to "1024" for maximum CPU resources.
at "32" it works well.
i normally only use my max stuff in pluggo form (where you
have exactly that, a vector size of 32 all over the runtime
due to the VST interface.) so i didnt notice this weird
setting for about 2 years.
still, there is this little hickup syndrome in my metro, even
at a proper vector size.
-110
Quote: andrewb@cycling74.com wrote on Wed, 07 March 2007 12:15
----------------------------------------------------
> If you are going to do anything with signal rate timing, I highly
> recommend looking into and fully understanding the following objects:
> sync~
> rate~
> zigzag~
> adsr~
> pong~
> edge~
> >~,
> index~
> +=~
> and of course clever use of buffer~.
>
> Being able to use these objects with some finesse should allow you to
> solve most problems that you will come up against with managing a
> signal-based timing structure.
Definitely true, but none of them can be used effectively in the example I posted earlier in order to synchronize the rates of the signals needed for the [stutter] objects.
rate~ comes the closest, but it suffers from two drawbacks:
1. it can easily be made to crash by fooling around with the time-scale around 0.
2. it cannot be made to stop independantly.
It also needs the ability to rescale itself accurately to buffers of varying lengths with sample accuracy, which it could, but there are no explicit messages to send it to do so (both floats and signals do not give this accuracy. For instance, if the first buffer is 1003ms and the second is 905, how can you express this to rate~ in order to have both samples played back with the right velocity?)
All of this is not to say that what I want cannot be done; I have been happily using my looper for quite a while now with several phasors. It is just good to see if I missed something useful.
Dayton skrev:
> Quote: Mattijs wrote on Wed, 07 March 2007 06:26
> ----------------------------------------------------
>
>
>> The correct answer is that if you want to have different loops play in sync, drive them all with one phasor. I can imagine that to do this, groove~ is less suitable than for instance play~.
>>
>
> ----------------------------------------------------
>
> Yes, but that would preclude any possibility of pitch-bending and/or phase-shifting the individual loops, which is one of the reasons I got into Max/MSP in the first place.
I am sorry if this has been replied to before:
If you drive all your loops from one phasor~ you can indeed to
pitch-bending and phase-shifting - pitchbending can be done by adding or
subtracting with an envelope from the phasor output (or manipulating
rate~ objects?), and phase-shifting is as simple as adding or
subtracting static values.
I am sure that you have tried these options though, so I am curious as
to why they do not do what you want?
Quote: Wetterberg wrote on Thu, 08 March 2007 02:31
----------------------------------------------------
> I am sure that you have tried these options though, so I am curious as
> to why they do not do what you want?
----------------------------------------------------
I went back and tried them again to make sure that I hadn't missed something back then. The pitchbend-comparison is in the patch above. Here are my experiences:
rate~ can crash if you have it locked-mode and pass the time-scale through 0 a few times. (Max/MSP ver. 4.5.5, Pentium 4 3GHz, 1GB RAM, MAudio MobilePre, 44100Hz, I/Ov128 sv64) Also, it can't be made to stop (although, of course it can be gated.) In addition, if I am dealing with loops of different lengths, the rate~ must be adjusted accordingly, and it cannot be adjusted with sample accuracy by either a float or a signal due to the decimal-precision. There are workarounds, but multiple phasors are more straightforward.
Simple mathematical manipulation of the phasor's signal is fine for fixed values, but doesn't work for changing dynamically. Try it out in the patch; it sounds awful with both floats and signals (why? I don't know).
In theory, there should be another solution, but I tried everything I could think of and this was what worked. The functionality must allow:
Complete freedom of playback-rate and direction for each loop
Complete freedom of length for each loop
Recalibration of the phase for each loop
Quantizable loop-lengths
Dynamic changes in each aspect (for use in live-performances)
Believe me, I would prefer to work with rate~, and there may be some unwanted upper limits in the use of individual phasors, but this is what works.
if you use +=~ and play~ you can easily create smooth pitchbending/pitch curves. i use a master phasor~ to trigger a sah~ object that samples the current value of +=~ and subtracts that value from the output of said +=~ effectively resetting it at sample rate. the only drawback is that +=~ gets enormous quite quickly, and this can cause roundoff errors, the sound gets crunchy, so you have to reset it to zero now and again.
maybe not so elegant but it works for me
I find it kind of interesting to how this debate have evolved.
I ask something i think is very simple(looping, overdubbing) from a musical point of view, and of you go discussing lowlevel technical aspects of the software proposed for creating the mucisians tools :-)
It is i think part of the big problem.
Why isn't this as simple to model as it is simpel to me to "think" i wonder?
I (just) need some loop audio reels running. I need a possibillity to record on these reels. And above all i need the reels to spin in synch. It is to me a simple problem, no matter how much i understand your discussion.
I guess i visualize it as and old tape loop system. Now thats simple right :-7
Not to be a drag or anything, but could we get this thread back on the looper/sound-on-sound track?
Please post working examples of small working looper systems, prefereable with overdubbing. Otherwize please provide more perspective on how to design with dsp versus messaging to.
thanks all so far!
Why isn't this as simple to model as it is simpel to me to "think" i wonder?
because your concious mind is filtering out nearly all of the information processing which is ocurring in your brain.
if you don't want to code then use Radial or Live or Traktor. max msp is akin to your computer taking LSD. anything is possible, but mostly its overwhelmingly incomprehensible and you cant even work out how to make first steps. your community will support you!
-frankly, Using an visually oriented system as Max, i'd expect NOT to code.
If you go ahead and model pieces of inner computer machinery at a certain abstraction level, i'd say you perhaps need to complement that with severel models from the music-world to reach something greater. -To pair the to worlds i mean.
I find completely "funny" to expect musicians to work with max when it dosn't model stuff like:
String, Drum head, Reel, and so on....
Drugs....hmmm - i guess also bad for computers :-!
it will do all of that stuff if you tell it how to do it. have a look at the SOS synth secrets series for ideas for basic concepts to start from in modelling real instruments.
maxmsp doesnt assume anything about what is musically useful, which makes it harder to use, but is also the reason why i personally am using it.
tools such as drugs or software are neither necessarily good nor bad imo. is a knife good?
In stead of talking, let's just use your knife to cut to the case:
Any sampleaccurate loopers/overdubber example pathers would be greatly appreciated!
I see what you are working on.
First a very basic question: you are aware of the fact that if you want to pitch a loop down, it will also play slower, right? When one loop plays slower than the other, you'll agree that there is no notion of sync anymore...
To answer your questions directly:
> 1. Any real-time changes cause ugly clicks
That's true. See above, not only the pitch changes, the position changes too. So your cursor jumps to another point in the sample, causing a click. This is a basic design issue. My original statement about playing a loop with a different pitch is not of much use in most synced sample loop situations but was merely to show that anything you want to do should be derived from one audiorate sync source. I think in your case you need pitch shifting (granular or spectrum based, for an example see help file of gizmo~) instead of resampling (which is what you do if you play at another rate than 1).
> 2. I can't go backwards with one loop and forward with another
Why not? You can all derive it from the master phasor. Like this for example:
> 3. The numbers I feed to [/] or [+] do not give me an accurate representation about what I am doing to the sound (although a bit of dynamic scaling would).
I don't understand this point. What numbers do you feed to them? What representation do you want them to give you? Of which sound? What do you mean with dynamic scaling? Not to be annoying, just to give you an impression of where my understanding goes wrong.
I'm tempted to let you explain your final goal and implement it for you, just to prove my point to everyone on the forum ;) But I don't have many spare time at the moment..
Best,
Mattijs
Quote: Dayton wrote on Wed, 07 March 2007 18:59
----------------------------------------------------
> That threw me for a bit, so I tried it out. No go (although I don't rule out the possibility of my being extremely dense at the moment.) There are three problems to this approach:
> 1. Any real-time changes cause ugly clicks
> 2. I can't go backwards with one loop and forward with another
> 3. The numbers I feed to [/] or [+] do not give me an accurate representation about what I am doing to the sound (although a bit of dynamic scaling would).
>
> Basically, I need to be able to do anything with the (in my case) [stutter] objects individually and collectively, and sync them back up on command.
> I would love to use only one phasor for this patch, so I would be more than happy if you prove me wrong.
Quote: Roman Thilenius wrote on Wed, 07 March 2007 20:48
----------------------------------------------------
>
> >> 1/64 note at 120 bpm =~ 8 ms, a factor 0.25 off =~ 2 ms.
> >> That's very well possible considering that the scheduler
> >> event interval is 2 ms by default.
>
>
> a 64th is normally 31.25 or 62.5 ms long @ 120 bpm, depending
> on how you count.
> well or 8 - depending how you count! :)
Ah, sorry, I was thinking about 1/64 beat instead of 1/64 note, hehe, sorry. Of course 1/64 note is around 31 ms. But then I don't understand your problem.
>
> but try this:
>
> max v2;
> #N vpatcher 60 709 784 1054;
> #P toggle 49 42 38 0;
> #P user ezdac~ 49 194 93 227 0;
> #P newex 49 140 105 196617 click~;
> #P newex 49 102 105 196617 metro 125;
> #P connect 3 0 0 0;
> #P connect 0 0 1 0;
> #P connect 1 0 2 0;
> #P connect 1 0 2 1;
> #P pop;
>
> if there is anybody who can tell if those beats are straight
> or punctuated he/she obviously know more about metro than
> kasper and me. :) to me it sounds more like "random" than
> like "sequencing".
But.. am I crazy or do I totally miss the point? I hear a steady sequence of clicks. No hearable randomness at all. I can imagine that the clicks are up to 2 ms off but I can't hear that. Could you record what you hear and then attach it?
>
> (btw, according to your theory above those are half notes, LOL.)
My bad. Sorry. Lol :)
>
>
>
> > > and phasor~ ... how many posts have there been this month
> > > abolut how to reset phasors phase ? :)
> >
> > I missed those.. is there something wrong with a 0 in the right outlet?
>
>
> ... it does not accept signals, so when you need to sync 35
> phasors (which is why we want to reset phase) you have
> a problem.
Ok, that really sounds like a situation where you should have used one master phasor.
Mattijs
>
> or was it cycle~ what i had in mind here?
>
>
>
>
>
----------------------------------------------------
Quote: McSkelle wrote on Thu, 08 March 2007 14:28
----------------------------------------------------
> -frankly, Using an visually oriented system as Max, i'd expect NOT to code.
I think a visual programming language might very well require more technical skill than textbased code. But...
> I find completely "funny" to expect musicians to work with max when it dosn't model stuff like:
> String, Drum head, Reel, and so on....
...the question is: is max aimed towards musicians? I say: no. And voila, there's the reason for this ongoing discussion.
I hope I didn't just mess up cycling 74's marketing stretegy? ;)
Cheers,
Mattijs
Quote: Roman Thilenius wrote on Wed, 07 March 2007 21:05
----------------------------------------------------
>
> > >> 1/64 note at 120 bpm =~ 8 ms, a factor 0.25 off =~ 2 ms.
> > >> That's very well possible considering that the scheduler
> > >> event interval is 2 ms by default.
> >
> >
> > a 64th is normally 31.25 or 62.5 ms long @ 120 bpm, depending
> > on how you count.
> > well or 8 - depending how you count! :)
>
>
> we are all a bit retarded i think.
>
> i just noticed that on my "developer" computer i had the
> signal vector size set to "1024" for maximum CPU resources.
>
> at "32" it works well.
Ah, I see. Forget my previous reply then.
> i normally only use my max stuff in pluggo form (where you
> have exactly that, a vector size of 32 all over the runtime
> due to the VST interface.) so i didnt notice this weird
> setting for about 2 years.
>
> still, there is this little hickup syndrome in my metro, even
> at a proper vector size.
Not in mine.. as far as I can hear.
>
>
> -110
>
>
>
>
>
>
----------------------------------------------------
Quote: McSkelle wrote on Thu, 08 March 2007 15:45
----------------------------------------------------
> In stead of talking, let's just use your knife to cut to the case:
>
> Any sampleaccurate loopers/overdubber example pathers would be greatly appreciated!
----------------------------------------------------
This is how I would start:
Mattijs
> ...the question is: is max aimed towards musicians? I say: no. And voila, there's the reason for this ongoing discussion.
>
yeah, where' all the uber Max music to be found? I have heard very little music made with Max/PD...
I guess https://cycling74.com/c74music might be a good
place to start...
cheers
Roger
--- jamez wrote:
>
> yeah, where' all the uber Max music to be found? I
> have heard very little music made with Max/PD...
>
>
Depends on the Circles you travel and the type of music you listen
to. But I hear it all the time....
On Mar 8, 2007, at 11:28 AM, jamez wrote:
>
>
>> ...the question is: is max aimed towards musicians? I say: no. And
>> voila, there's the reason for this ongoing discussion.
>>
>
>
> yeah, where' all the uber Max music to be found? I have heard very
> little music made with Max/PD...
>
>
v a d e //
www.vade.info
abstrakt.vade.info
>yeah, where' all the uber Max music to be found? I have heard very
little music made with >Max/PD...
I guess you haven't visited the Cycling '74 myspace page. Seems all of
our friends are making music:
>...the question is: is max aimed towards musicians?
> I say: no.
To clarify, Max doesn't really make too many assumptions about what you
are - musician, artist, civil engineer, interaction designer, video
artist, VJ, etc. You get to decide what MaxMSP is for.
Happy Patching,
Andrew B.
Well I think it takes a smart musician to learn how to
use max. I would say most electronic music producers
end up using easier tools like Reason-ish apps.
I think you can tell when someone is really trying to
do something innovative, more often than not they are
using Max or SuperCollider. For example: can you tell the
difference between Autechre and Richard Devine?
But if you were to go see a laptop musician, I doubt you
would be able to tell what all was used in producing
every aspect of the production. I regularly see a lot of
music that uses Max, in fact they all tend to be live electro
acoustic music performances because that is what Max excels
at: the performance environment.
Anthony
----- Original Message -----
From: vade
Date: Thursday, March 8, 2007 10:44 am
Subject: Re: [maxmsp] Re: Talking 'bout tightness
> Depends on the Circles you travel and the type of music you listen
>
> to. But I hear it all the time....
>
> On Mar 8, 2007, at 11:28 AM, jamez wrote:
>
> >
> >
> >> ...the question is: is max aimed towards musicians? I say: no.
> And
> >> voila, there's the reason for this ongoing discussion.
> >>
> >
> >
> > yeah, where' all the uber Max music to be found? I have heard
> very
> > little music made with Max/PD...
> >
> >
>
> v a d e //
>
> www.vade.info
> abstrakt.vade.info
>
>
>
>
Mattijs: Thanks!
Here is a super-simple example of doing a signal-based loop/overdub
patch. This should maintain timing "tightness".
Happy Patching,
Andrew B.
...and if you want an interpolating buffer writer (when you go faster
than 1 sample per sample) use my free ipoke~
www.no-tv.org/MaxMSP
pa
btw, real-time triggered loopers, with 2 ms tighness, is still
tighter than most drummer on earth... here is my real-time looper
that I use with real musicians... you need hr objects though
Can't seem to find a download site for the hr object. Could anybody provide an URI?
You were right, but perhaps not in the same way you thought:
Quote: Mattijs wrote on Thu, 08 March 2007 08:08
----------------------------------------------------
> I see what you are working on.
>
> First a very basic question: you are aware of the fact that if you want to pitch a loop down, it will also play slower, right? When one loop plays slower than the other, you'll agree that there is no notion of sync anymore...
Only until you stop pitch-bending, then the sync is the relationship between the length of the loops, which is what I consider important, not to get them all the same length
> > 2. I can't go backwards with one loop and forward with another
>
> Why not? You can all derive it from the master phasor. Like this for example:
>
>
I mean dynamically (twiddling dials and such.) The above code cannot go from forward playback to backward playback by going from positive to negative while playback is going on. Using this discussion as an impetus, however, I have come to agree with you that I can, indeed use only one controlling instance, although for my purposes this is not phasor (patch below)
> > 3. The numbers I feed to [/] or [+] do not give me an accurate representation about what I am doing to the sound (although a bit of dynamic scaling would).
>
> I don't understand this point. What numbers do you feed to them? What representation do you want them to give you? Of which sound? What do you mean with dynamic scaling? Not to be annoying, just to give you an impression of where my understanding goes wrong.
This is just to say that I wanted to express the manipulations in terms of samples instead of mathematical operations based on frequency, miliseconds, etc. (Solution below)
OK, I spent some time experimenting this morning, and found the answer to my problems in the [count~] object, which I hadn't used before. This finally gave me the opportunity to give [stutter] a specific number of samples to grab as well as a playback signal based on exactly that number of samples. When using loops of different lengths simultaneously, the relationships of length given as a proportion to the [rate] object could cause anomalies which resulted in small differences of playback rate, specifically in the case of lengths of a third, sixth, etc. In the past, I had been measuring in miliseconds and converting them back to samples, then to frequencies. In this patch, you can choose the [count] object instead of the phasor and at least start with an accurate number of samples.
Using [rate] allows for smooth bending (as long as it is set to "sync off") and accurate multiples of the first loop-length, but if the subsequent loop-length doesn't divide evenly into the first, it will get out of rhythm (particularly crucial in cases of loops being three times the original length). In my performance patch, I deal with this by quantizing the original loop-length to allow for the pre-selected subdivisions and quantizing the subsequent loops as well. When using free lengths it is unimportant that the loops are a few samples off.
So, you were right, it is possible to use a single playback-signal to drive multiple loops regardless of direction, length and rate, but not without preparing the output first.
Here is the updated test-patch, allowing experimentation with various types of signal-manipulation:
Quote: Dayton wrote on Fri, 09 March 2007 13:50
----------------------------------------------------
> You were right, but perhaps not in the same way you thought:
>
> Quote: Mattijs wrote on Thu, 08 March 2007 08:08
> ----------------------------------------------------
> > I see what you are working on.
> >
> > First a very basic question: you are aware of the fact that if you want to pitch a loop down, it will also play slower, right? When one loop plays slower than the other, you'll agree that there is no notion of sync anymore...
>
> Only until you stop pitch-bending, then the sync is the relationship between the length of the loops, which is what I consider important, not to get them all the same length
Ok, that's an option. That means that the loop has a time offset after bending back to pitch 1 and every time you bend the pitch this offset will change, correct? Or maybe the loop will jump to the beginning every cycle?
>
> > > 2. I can't go backwards with one loop and forward with another
> >
> > Why not? You can all derive it from the master phasor. Like this for example:
> >
> > #P user number~ 124 142 163 157 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P user number~ 67 142 106 157 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P newex 124 120 36 196617 !-~ 1.;
> > #P newex 67 93 46 196617 phasor~;
> > #P connect 0 0 2 0;
> > #P connect 0 0 1 0;
> > #P connect 1 0 3 0;
>
> I mean dynamically (twiddling dials and such.) The above code cannot go from forward playback to backward playback by going from positive to negative while playback is going on. Using this discussion as an impetus, however, I have come to agree with you that I can, indeed use only one controlling instance, although for my purposes this is not phasor (patch below)
Allright, if I understand you correctly this is similar to the pitch controller, only pitch also enters negative values.
Good that you found an alternative, but after a quick glance at your patch I still have the strong feeling that your approach is unnecessarily difficult. Preparing the output shouldn't be necessary. Your idea is in the line of a project I am working on so if I have time this weekend I'll try to remake your patch according to my ideas, if you don't mind of course.
Best,
Mattijs
Quote: Mattijs wrote on Fri, 09 March 2007 06:34
so if I have time this weekend I'll try to remake your patch according to my ideas, if you don't mind of course.
On the contrary; I would be flattered.
After trying a few different approaches and looking back over what I did a year ago, I am came very close today to having a general looping-platform which enables me to loop using a number of approaches. Since all of them seem to work, however, it is difficult to decide how to test them against each other.
The only reason I ended up using [Stutter] was for a live-improvisation situation in which the musicians (or, in my case, actors) could decide after playing or saying a phrase if they wanted to use it (there is no start-record, stop-record; just "loop everything since the beginning of the last phrase" (using a threshhold trigger)). This still seems the best approach for that purpose, but I think the patch I am finishing up now will allow me to use several approaches by simply replacing the subpatch-name in the [poly]. Stutter takes up more than twice the memory that a buffer-based approach would, so I will see if I can get what I normally need without it.
Roman Thilenius schrieb:
> if you use metro, you are using a message system.
>
> 2 messages (bang) coming out of metro, connected to 2
> somethings, will NEVER arrive at their aims at the same time.
>
> 2 samples (for example an "1." sample, a click),
> will ALWAYS arrive at the same time when connected to 2
> aims. (or to be exact, _within the same sample)
messages and samples do not differ in principle, but in the time range
they occur. Your NEVER and your ALWAYS apply to both:
ALWAYS in the sense of your "to be exact, _within the same sample", is
for messages mostly "within the same tick". If you overload the
scheduler your messages get backlogged though, in audio rate you'd get
crackles if you overload the processor (sounds worse than untightness...)
In audio rate samples will not always arrive in the same sample, that
depends on the type of process/external you are using, some things
happen once within a signal vector. And if "scheduler in audio
interrupt" is switched on, the scheduler interval is bound to the signal
vector...
If you overload your processor you will have timing problems. If you
don't it doesn't make such a big difference. If you have a signal vector
of 64 samples, you'll have your timing tight to less than 1.5 ms...
If you feel fine with Midi tightness, you should be fine with scheduler
control as well, but you have to set your performance options carefully...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Mattijs Kneppers schrieb:
> If we could bundle this test with a few others, together with clear
> and simple clarifications and finally notes and examples how to
> approach possible issues in the correct way, we'd have a real
> solution for the everlasting 'metro' misunderstanding.
Yes, I modified the patch a bit, to be able to see the exact difference
as well as to be able to play with the settings within the patch. It
verifies quite clearly my statement about less than 1.5 ms with a vector
size of 64 and scheduler in audio interrupt/overdrive on...
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Kasper T Toeplitz schrieb:
> with working patches (audio ok, no cliks etc) i am more often in the
> 1000-1300 range!
Then you didn't set "scheduler in audio interrupt" on...
Or you totally overload the scheduler which is also possible. Then you
have to get rid of all these snapshot~s and replace them with edge~
constructions. And avoid very short metros if possible. Anything which
is polled, needs some time to eat CPU for breakfast, lunch and dinner.
They are always hungry those objects...
Especially some of the fft analysis objects are hungry, and need to be
offset against each other, elsewise they want to eat CPU all at the same
time and you get the typical traffic jam you know from the peripherique
in Paris... (If you ask your metro/friend to be in time, for sure
they'll be late... ;-)
On the Mac you can see how much you push the processor with the activity
monitor...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
f.e schrieb:
> @ Stefan Tiedje :
>
> 1 - i took a look at your metro~ (cf. abhaxions), but without any help
> file, i still wonder what to do with the 3rd inlet...
BPM instead of milliseconds (you could open them and see... ;-)
> 2 - why did you set the initial phase to 0.499 instead of 0.5 ? it
> scares me to think this is a workaround because even phasor~ has its own
> problem ?
I forgot, why I did it, probably to get the first bang out immediately.
You can experiment with some settings and change the values, maybe it
was stupid... I usually just leave things as they are if they work for
me. If you find concrete problems, don't hesitate to correct them and/or
report them...
The help file should be in the collection..., but here it is again:
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
>Kasper T Toeplitz schrieb:
>>with working patches (audio ok, no cliks etc) i am more often in
>>the 1000-1300 range!
>
>Then you didn't set "scheduler in audio interrupt" on...
>Or you totally overload the scheduler which is also possible. Then
>you have to get rid of all these snapshot~s and replace them with
>edge~ constructions. And avoid very short metros if possible.
>Anything which is polled, needs some time to eat CPU for breakfast,
>lunch and dinner. They are always hungry those objects...
>Especially some of the fft analysis objects are hungry, and need to
>be offset against each other, elsewise they want to eat CPU all at
>the same time and you get the typical traffic jam you know from the
>peripherique in Paris... (If you ask your metro/friend to be in
>time, for sure they'll be late... ;-)
>On the Mac you can see how much you push the processor with the
>activity monitor...
hi stefan
no I didn't set "scheduler in audio interrupt" on
but then no snapshot~ and no very short metros ( 5000 is not short, right ?)
I use metro in paris and am never late
i wish the one in max would work as it is supposed to. It does not,
so i build my own metro~ (which i discovered to be very close to your
metro~ so I changed the name)
all the best
kasper
--
Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com
Quote: Kasper T Toeplitz wrote on Sat, 10 March 2007 13:40
----------------------------------------------------
> i wish the one in max would work as it is supposed to. It does not,
I can't believe that you keep insisting that metro doesn't work correctly if so many experienced people repeat over and over that there's nothing wrong with it.
Mattijs
I need an advice what's the best equipment(laptop,
interface,etc) to use when setting up digital
Audio/Video for
corporate events, and also if anyone had ever used
MAX/MSP for
that before?
thanks
Anya
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367
> I can't believe that you keep insisting that metro doesn't work correctly if so many experienced people repeat over and over that there's nothing wrong with it.
It's still not clear what precisely is wrong with working
in the signal domain [metro was always an artifact of the old
event-level Max world], but I would think that the arrival
of Eric Lyon's elegant and flexible samm~ object would
change things a little; it's a marvelous piece of work.
>
>
>> i wish the one in max would work as it is supposed to. It does not,
>
>I can't believe that you keep insisting that metro doesn't work
>correctly if so many experienced people repeat over and over that
>there's nothing wrong with it.
ok, i know (now) about all the reasons, blablabla, scheduler, osX,
all those things
but even if experienced people repeat over and over that all is fine
when i read in the ref manual ". At regular intervals,
metro sends a bang out the outlet."
and my metro does not send a bang at REGULAR intervals (unless you
say than anything in the 1000-1300 range is regular) - that's why I
keep insisting it is not working correctly.
I learned how NOT to use this object to do what i want (all my
patches have a time counter - I used to use a metro to drive them,
now i use other things, audio domain). But it seems to me it is not
working as it says it would.
G Taylor talks about samm~, there is metro~ etc... still, if talking
about metro, i feel it does not sends a bang at regular intervals. It
does it sometimes, sometimes not. Which is not how i would define
regular, belive it
all the best
kasper
--
Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com
Hi Dayton,
Here is my approach. It illustrates the technique I think is best for looping with separate pitch per loop, derived from one master phase without leaving the dsp domain.
Best,
Mattijs
Make sure you save and load the file to fire all loadbangs..
Quote: Dayton wrote on Fri, 09 March 2007 19:46
----------------------------------------------------
> Quote: Mattijs wrote on Fri, 09 March 2007 06:34
> so if I have time this weekend I'll try to remake your patch according to my ideas, if you don't mind of course.
>
>
> On the contrary; I would be flattered.
> After trying a few different approaches and looking back over what I did a year ago, I am came very close today to having a general looping-platform which enables me to loop using a number of approaches. Since all of them seem to work, however, it is difficult to decide how to test them against each other.
ok... heres a FAR FAR out solution.
IF you had a matrix whose width was the vector size, and height was 1. then you could represent bangs and/or integers in audio rate.
if you made it 2 dimensional, you could represent any max message at audio rate.
if someone (**NOT ME**) wrote some objects on that principal, you could have audio rate max messages.
whoa.
I know this is going to piss some people off, but Gregory Taylor once told me that PD had an option to make any patcher run at any sampling rate. More malulable sampling rates and datatypes really seems to be a common solution.
this is the method i use for smooth sample rate pitchbending and curves using a phasor~ driven system. the only drawback with the bare bones system is that +=~ will get big after a while, causing round off errors
Kasper T Toeplitz schrieb:
> but then no snapshot~ and no very short metros ( 5000 is not short,
> right ?)
These are the scheduler killers anyway. You do not want to use shorter
than 10 ms metros in scheduler. It's already thought as audiorate, even
if its slower than unaudible. Musical metros will go up to 64ths, and
that's already. And as I said before, snapshots~ do eat your non-audio
rate cycles. Try to get rid of them or bang them rarely...
This explains very well your problems... Its not the metro, its the way
you treat it...
> still, if talking about metro, i feel it does not sends a bang at
> regular intervals. It does it sometimes, sometimes not. Which is not
> how i would define regular, belive it
It does so for me,
but then if I overload my CPU I would not get a simple cycle~ put out a
sine wave, it would crackle, though the manual states it puts out a sine...
The same for scheduler overload, if I demand too much, none of any
object will be able to work as advertised...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
>Kasper T Toeplitz schrieb:
>>but then no snapshot~ and no very short metros ( 5000 is not short, right ?)
>
>These are the scheduler killers anyway. You do not want to use shorter
>than 10 ms metros in scheduler. It's already thought as audiorate, even
>if its slower than unaudible. Musical metros will go up to 64ths, and
>that's already. And as I said before, snapshots~ do eat your non-audio
>rate cycles. Try to get rid of them or bang them rarely...
>
>This explains very well your problems... Its not the metro, its the way
>you treat it...
>
>>still, if talking about metro, i feel it does not sends a bang at
>>regular intervals. It does it sometimes, sometimes not. Which is
>>not how i would define regular, belive it
>
>It does so for me,
>but then if I overload my CPU I would not get a simple cycle~ put out a
>sine wave, it would crackle, though the manual states it puts out a sine...
>The same for scheduler overload, if I demand too much, none of any
>object will be able to work as advertised...
>
hi Stafan
sorry my answer was to be read
but then I USE no snapshot~ and USE no very short metros ( 5000 is
not short, right ? I MOSTLY USE LONG METROS, 1000 AND UP)
so thank you for your explainantion, but it does not explain my
problems. , Not at all (and i don't overload my CPU, at least not
according to the activity monitor)
____
if you open the simple example i am sending (based on you own metro~
object) you can see that "timer" does not work very well (yes, i
know, it is the same thing than with metro - scheduler, osX etc..)
_if i suppose your metro~ works well (it should, since it is in the
audio domain) then the timer does not (the reported time is ALWAYS
superior to 1000
all the best
kasper
Quote: Matthew Aidekman wrote on Sun, 11 March 2007 18:08
----------------------------------------------------
> I know this is going to piss some people off, but Gregory Taylor once told me that PD had an option to make any patcher run at any sampling rate. More malulable sampling rates and datatypes really seems to be a common solution.
The event system in max is not sample based so the term sampling rate is not applicable to metro. Have a look at the docs about threading to find out more.
Mattijs
poor choice of words... it was a casual conversation.
apologies.
the point was that if the maxer could quantize time at different intervals for different applications, the problem would be solved.
I may be completely and utterly wrong about Senior Taylors implications.
Just for my 2 cents. I've been going through my own little slice of hell with Max lately, writing a patch that does much heavy lifting of relatively light object - that is, on basic midi info. It doesn't use any metro objects, but it does send *lots* of messages, and I think what's basically made my life hell is that the scheduler just can't cope after a certain point. I realize that my mistake was in making a modular design that didn't scale well to the number of instances I was ultimately after, so I'm going to have to rethink the modularity of the design. In that sense it's definitley my fault.
But I would also have to say that, in my ten years experience, the scheduler has been a somewhat fragile beast. Most of what I've done over the past couple of years has been based on the idea of composing in real time for large ensemble and/or orchestra. And when the number of events reaches a certain point, Max gets really cranky. Timing goes for a wander (backlog), which starts a nasty process of the app basically tearing itself apart. In the past I've either given up, or slowly designed my way to working solutions. But on a purely superficial level, in the sense of looking at the patches in terms of what each object/external/abstraction is documented to do, how messages logically flow from one to the next, and given the basic principles of how Max works, these apps have not been incorrectly designed. Inefficiently, perhaps. But not incorrectly. So, in a sense, they 'should' have worked. And I think that's the basic frustration with the so called 'wandering' metro. You could work your way around it with a deeper understanding of how the system uses Max. But that is actually beyond the scope of what the Max objects themselves claim to do. So, in a sense, it's correct to say that the metro wanders, and it's also correct to say that "used properly" it doesn't. The question is whether or not using it properly should require more than a solid understanding of the documented functions of the built-in Max objects.
J.
Quote: Kasper T Toeplitz wrote on Sat, 10 March 2007 18:23
----------------------------------------------------
> >
> >
> >> i wish the one in max would work as it is supposed to. It does not,
> >
> >I can't believe that you keep insisting that metro doesn't work
> >correctly if so many experienced people repeat over and over that
> >there's nothing wrong with it.
>
>
> ok, i know (now) about all the reasons, blablabla, scheduler, osX,
> all those things
>
> but even if experienced people repeat over and over that all is fine
> when i read in the ref manual ". At regular intervals,
> metro sends a bang out the outlet."
>
> and my metro does not send a bang at REGULAR intervals (unless you
> say than anything in the 1000-1300 range is regular) - that's why I
> keep insisting it is not working correctly.
>
> I learned how NOT to use this object to do what i want (all my
> patches have a time counter - I used to use a metro to drive them,
> now i use other things, audio domain). But it seems to me it is not
> working as it says it would.
>
> G Taylor talks about samm~, there is metro~ etc... still, if talking
> about metro, i feel it does not sends a bang at regular intervals. It
> does it sometimes, sometimes not. Which is not how i would define
> regular, belive it
>
> all the best
>
> kasper
> --
> Kasper T. Toeplitz
> noise, composition, bass, computer
> http://www.sleazeArt.com
>
> http://www.myspace.com/sleazeart
>
>
>
----------------------------------------------------
How about seq~? While two dimensions wouldn't be enough to represent a
list, seq~ is a great help for looping control-rate events.
>
> ok... heres a FAR FAR out solution.
>
> IF you had a matrix whose width was the vector size, and height was
> 1. then you could represent bangs and/or integers in audio rate.
>
> if you made it 2 dimensional, you could represent any max message at
> audio rate.
>
> if someone (**NOT ME**) wrote some objects on that principal, you
> could have audio rate max messages.
>
> whoa.
>
>
> I know this is going to piss some people off, but Gregory Taylor once
> told me that PD had an option to make any patcher run at any sampling
> rate. More malulable sampling rates and datatypes really seems to be
> a common solution.
>
>
www.petermcculloch.com
Quote: jbm wrote on Mon, 12 March 2007 23:49
----------------------------------------------------
> You could work your way around it with a deeper understanding of how the system uses Max.
-And- a deeper understanding of how Max uses the system. But that's not working around, that's using properly.
> But that is actually beyond the scope of what the Max objects themselves claim to do.
I agree, but only if max objects claim to be black boxes. And yes, their graphic representation strongly suggests this. But they are not, at least not when things get serious.
> So, in a sense, it's correct to say that the metro wanders, and it's also correct to say that "used properly" it doesn't. The question is whether or not using it properly should require more than a solid understanding of the documented functions of the built-in Max objects.
Couldn't have said it better. And I can answer that question: if you don't have the level of understanding of an audio software engineer, you are going to run into trouble sooner of later. Probably later, but still.
Mattijs
Quote: andrewb@cycling74.com wrote on Thu, 08 March 2007 18:03
----------------------------------------------------
> To clarify, Max doesn't really make too many assumptions about what you
> are - musician, artist, civil engineer, interaction designer, video
> artist, VJ, etc. You get to decide what MaxMSP is for.
>
> Happy Patching,
> Andrew B.
>
----------------------------------------------------
Hi Andrew,
I think you are right to keep this open. But the reactions to these threads seem to call for guides of some sorts for people with various backgrounds.
You'll probably agree that it's really hard for someone without a technical background to successfully complete an interactive installation or a software synthesizer or even to sync a few loops in Max. Not only because you need a certain level of technical skill but also because you need certain basic knowledge about how the OS works, how a computer program utilizes resources, what are possible bottlenecks, how threads work, in general stuff that you learn in a computer-oriented education.
And I suspect that this is not always clear to everyone. In a way Max is a dream for a lot of people that feel that they're never going to learn enough of C++ to make their own software from scratch. In a lot of cases this dream is shattered when the project gets more serious. It would be good if the expectations would match a little better with practice.
In my opinion easy accessible basic courses about computer programming aimed towards the different target audiences that you mention above, that has people realise the limits that come with different backgrounds and limitations in experience and knowledge, could do wonders.
Best,
Mattijs
Quote: Mattijs wrote on Tue, 13 March 2007 11:50
----------------------------------------------------
> Quote: andrewb@cycling74.com wrote on Thu, 08 March 2007 18:03
> ----------------------------------------------------
> > To clarify, Max doesn't really make too many assumptions about what you
> > are - musician, artist, civil engineer, interaction designer, video
> > artist, VJ, etc. You get to decide what MaxMSP is for.
> >
> > Happy Patching,
> > Andrew B.
> >
> ----------------------------------------------------
>
> Hi Andrew,
>
> I think you are right to keep this open. But the reactions to these threads seem to call for guides of some sorts for people with various backgrounds.
>
> You'll probably agree that it's really hard for someone without a technical background to successfully complete an interactive installation or a software synthesizer or even to sync a few loops in Max. Not only because you need a certain level of technical skill but also because you need certain basic knowledge about how the OS works, how a computer program utilizes resources, what are possible bottlenecks, how threads work, in general stuff that you learn in a computer-oriented education.
>
> And I suspect that this is not always clear to everyone. In a way Max is a dream for a lot of people that feel that they're never going to learn enough of C++ to make their own software from scratch. In a lot of cases this dream is shattered when the project gets more serious. It would be good if the expectations would match a little better with practice.
>
> In my opinion easy accessible basic courses about computer programming aimed towards the different target audiences that you mention above, that has people realise the limits that come with different backgrounds and limitations in experience and knowledge, could do wonders.
>
>
I wonder if there might be some way of making a more user-friendly, and interactive debugging system. Maybe some sort of set of graphical "gauges" which would give us a sort of bird's-eye view on how our apps are using existing resources. Kind of like "top" or the Activity Monitor, but strictly *within* Max. For example, such a gauge could be made to reflect the relative work load, over time, of the audio thread, scheduler thread, and maybe even any java thread(s). Perhaps a system of thresholds could even be devised, whereby any gauge that read over a certain level would pop open the patcher/subpatcher which was introducing the bottleneck(?) I don't know... maybe that's just goofy. But something along those lines would be really helpful, I think. And as a side-benefit, it would give those with less background in computers a quick and intuitive way of learning about where problems tend to occur.
Does that sound possible?
J.
> Mattijs Kneppers said:
> But the reactions to these threads seem to call for guides of some sorts for people with various backgrounds.
I understand your frustration, but most of us here lack any kind of
"technical background". Granted, using Max will eventually trick you
into learning the kinds of computer science things you thought you were
avoiding by going to art school. At least, that has been my experience.
That said, I agree that we could do more in this area. In case you
hadn't noticed, we have been updating the website pretty regularly with
rather specific articles and tutorials that attempt to service the needs
left unserved by our documentation. We know that it is not totally
comprehensive at this point, but these things take a bit of time. As an
example, check out the tutorial I just posted on using joysticks and HID
devices in Max:
...or Darwin Grosse's thorough set of Rewire tutorials.
If those of you in the community find an area that is lacking in our
documentation, feel free to add an article to Vade's wiki, publish a
tutorial on your own site, post a thread to the forum, or contact us and
see if we'll post your article.
For anyone who is unclear about how the scheduler and queue work in Max,
I highly recommend JKC's rather elucidating article here:
Cheers,
Andrew Benson
Quote: andrewb@cycling74.com wrote on Tue, 13 March 2007 16:53
----------------------------------------------------
>
> > Mattijs Kneppers said:
> > But the reactions to these threads seem to call for guides of some sorts for people with various backgrounds.
> I understand your frustration, but most of us here lack any kind of
> "technical background".
Oh, but it's really not a matter of frustration. I just feel sincerely sorry for all the great people out there working with max, trying to work out ideas that I would love to see realised.
With the correct expectations their work would be so much more effective. When a vj with an art school background wants to make an interactive installation in max he could either choose to do it by himself and ultimately fail or ask the computer kid next door to take care of the technical stuff and end up with a tight installation with next level visuals. But he needs the proper information to make that decision.
> Granted, using Max will eventually trick you
> into learning the kinds of computer science things you thought you were
> avoiding by going to art school. At least, that has been my experience.
That's right, as soon as your ideas get a little complex you do need this basic computer science to work with max effectively. It's not bad that people are tricked into it (everybody should be a technician ;) but on the other hand perhaps, as illustrated above, it would be good to enable the user to make that decision for themselves. A few simple docs could help enormously (see below).
>
> That said, I agree that we could do more in this area. In case you
> hadn't noticed, we have been updating the website pretty regularly with
> rather specific articles and tutorials that attempt to service the needs
> left unserved by our documentation. We know that it is not totally
> comprehensive at this point, but these things take a bit of time. As an
> example, check out the tutorial I just posted on using joysticks and HID
> devices in Max:
>
> https://cycling74.com/story/2007/3/12/113645/135
>
> ...or Darwin Grosse's thorough set of Rewire tutorials.
I definitly noticed the articles, they are great. I absolutely agree that this is the way to go to solve this problem.
>
> If those of you in the community find an area that is lacking in our
> documentation, feel free to add an article to Vade's wiki, publish a
> tutorial on your own site, post a thread to the forum, or contact us and
> see if we'll post your article.
Well, time for someone to stand up and fix this!
>
> For anyone who is unclear about how the scheduler and queue work in Max,
> I highly recommend JKC's rather elucidating article here:
>
> https://cycling74.com/story/2005/5/2/133649/9742
Agreed. But unfortunately I also expect that without a level of technical experience you are probably not going to understand it, even though you do need this information desperately. I believe with this thread we're not far from an article about syncronized looping that is easier accessible than core issues such as how the scheduler and queue work in max.
Best,
Mattijs
That sounds beautiful! Models for display might include the 'hotspot'
style web page traffic analysis tools and the various drive storage use
visualizers.
jbmaxwell wrote:
> I wonder if there might be some way of making a more user-friendly, and interactive debugging system. Maybe some sort of set of graphical "gauges" which would give us a sort of bird's-eye view on how our apps are using existing resources. Kind of like "top" or the Activity Monitor, but strictly *within* Max. For example, such a gauge could be made to reflect the relative work load, over time, of the audio thread, scheduler thread, and maybe even any java thread(s). Perhaps a system of thresholds could even be devised, whereby any gauge that read over a certain level would pop open the patcher/subpatcher which was introducing the bottleneck(?) I don't know... maybe that's just goofy. But something along those lines would be really helpful, I think. And as a side-benefit, it would give those with less background in computers a quick and intuitive way of learning about where problems tend to occur.
> Does that sound possible?
Kasper T Toeplitz schrieb:
> _if i suppose your metro~ works well (it should, since it is in the
> audio domain) then the timer does not (the reported time is ALWAYS
> superior to 1000
For me its between 999 and 1001 with a vector size of 64, which is
exactly as expected. (less than 1.5 ms jitter as thats the duration of
the vector size if scheduler in audio interrupt is on)
The timer can only get its bang once a scheduler tick, but anytime
within that...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Quote: dlurk wrote on Wed, 14 March 2007 01:45
----------------------------------------------------
>
> That sounds beautiful! Models for display might include the 'hotspot'
> style web page traffic analysis tools and the various drive storage use
> visualizers.
>
Uhh.. guys. Shall we just start with error messages in the max window that link to the objects that caused them?
Mattijs
Quote: Mattijs wrote on Sat, 17 March 2007 21:31
----------------------------------------------------
> Quote: dlurk wrote on Wed, 14 March 2007 01:45
> ----------------------------------------------------
> >
> > That sounds beautiful! Models for display might include the 'hotspot'
> > style web page traffic analysis tools and the various drive storage use
> > visualizers.
> >
>
> Uhh.. guys. Shall we just start with error messages in the max window that link to the objects that caused them?
>
> Mattijs
----------------------------------------------------
hehe... yeah, okay. Fair enough!
Quote: Dayton wrote on Sat, 17 March 2007 21:40
----------------------------------------------------
> Hi Mattijs,
>
> I always get into these things right when I am about to go travelling; this is the first time I got back to the forum. I'll try your patch out when I get home, and thank you.
>
>
> Here is my stab at the problem; a basic patch and a subpatch to use in the poly.
Ok, I don't want to sound too rude cause it seems that you put quite some time in it but I'm quite sure that you could this with less than 1/4 of the amount of objects.
My example doesn't set the loop reference according to the recorded material but still I hope it'll help to simplify your patch.
Cheers,
Mattijs
A little supplement: to sync a phasor~ at audio rate you can use this:
Cheers,
Mattijs
very well put.
i share your over-scheduled pain.
On Mar 12, 2007, at 10:49 PM, jbmaxwell wrote:
>
> Just for my 2 cents. I've been going through my own little slice of
> hell with Max lately, writing a patch that does much heavy lifting
> of relatively light object - that is, on basic midi info. It
> doesn't use any metro objects, but it does send *lots* of messages,
> and I think what's basically made my life hell is that the
> scheduler just can't cope after a certain point. I realize that my
> mistake was in making a modular design that didn't scale well to
> the number of instances I was ultimately after, so I'm going to
> have to rethink the modularity of the design. In that sense it's
> definitley my fault.
>
> But I would also have to say that, in my ten years experience, the
> scheduler has been a somewhat fragile beast. Most of what I've done
> over the past couple of years has been based on the idea of
> composing in real time for large ensemble and/or orchestra. And
> when the number of events reaches a certain point, Max gets really
> cranky. Timing goes for a wander (backlog), which starts a nasty
> process of the app basically tearing itself apart. In the past I've
> either given up, or slowly designed my way to working solutions.
> But on a purely superficial level, in the sense of looking at the
> patches in terms of what each object/external/abstraction is
> documented to do, how messages logically flow from one to the next,
> and given the basic principles of how Max works, these apps have
> not been incorrectly designed. Inefficiently, perhaps. But not
> incorrectly. So, in a sense, they 'should' have worked. And I think
> that's the basic frustration with the so called 'wandering' metro.
> You cou!
> ld work your way around it with a deeper understanding of how the
> system uses Max. But that is actually beyond the scope of what the
> Max objects themselves claim to do. So, in a sense, it's correct to
> say that the metro wanders, and it's also correct to say that "used
> properly" it doesn't. The question is whether or not using it
> properly should require more than a solid understanding of the
> documented functions of the built-in Max objects.
>
> J.
Just curious: do (you think) you know exactly how the scheduler works? E.g. did you read jkc's article about threading in max?
- Mattijs
Quote: lists@lowfrequency.or wrote on Tue, 20 March 2007 14:46
----------------------------------------------------
> very well put.
> i share your over-scheduled pain.
>
>
> On Mar 12, 2007, at 10:49 PM, jbmaxwell wrote:
>
> >
> > Just for my 2 cents. I've been going through my own little slice of
> > hell with Max lately, writing a patch that does much heavy lifting
> > of relatively light object - that is, on basic midi info. It
> > doesn't use any metro objects, but it does send *lots* of messages,
> > and I think what's basically made my life hell is that the
> > scheduler just can't cope after a certain point. I realize that my
> > mistake was in making a modular design that didn't scale well to
> > the number of instances I was ultimately after, so I'm going to
> > have to rethink the modularity of the design. In that sense it's
> > definitley my fault.
> >
> > But I would also have to say that, in my ten years experience, the
> > scheduler has been a somewhat fragile beast. Most of what I've done
> > over the past couple of years has been based on the idea of
> > composing in real time for large ensemble and/or orchestra. And
> > when the number of events reaches a certain point, Max gets really
> > cranky. Timing goes for a wander (backlog), which starts a nasty
> > process of the app basically tearing itself apart. In the past I've
> > either given up, or slowly designed my way to working solutions.
> > But on a purely superficial level, in the sense of looking at the
> > patches in terms of what each object/external/abstraction is
> > documented to do, how messages logically flow from one to the next,
> > and given the basic principles of how Max works, these apps have
> > not been incorrectly designed. Inefficiently, perhaps. But not
> > incorrectly. So, in a sense, they 'should' have worked. And I think
> > that's the basic frustration with the so called 'wandering' metro.
> > You cou!
> > ld work your way around it with a deeper understanding of how the
> > system uses Max. But that is actually beyond the scope of what the
> > Max objects themselves claim to do. So, in a sense, it's correct to
> > say that the metro wanders, and it's also correct to say that "used
> > properly" it doesn't. The question is whether or not using it
> > properly should require more than a solid understanding of the
> > documented functions of the built-in Max objects.
> >
> > J.
>
>
----------------------------------------------------
Quote: Mattijs wrote on Tue, 20 March 2007 14:22
----------------------------------------------------
> Just curious: do (you think) you know exactly how the scheduler works? E.g. did you read jkc's article about threading in max?
>
> - Mattijs
>
I do "think" I know how the scheduler works, and yes I've read that article, and pretty much every other description of it I've found over the past 10 years. In fact, I just read it again, and I can say the same thing I said the last time I read it: what appears to be happening whenever I kill the scheduler is event backlog. Unfortunately, these are not patches that can accept any kind of speedlim procedure, since all the messaging that's going on is in some way essential to the process. Is it a case of bad or just overly-ambitious programming on my part? Quite possibly. On the bright side, my most recent project has enjoyed a great improvement in stability by a minor redesign which greatly reduced the number of messages crossing the max/java bridge. What can I say? I try. Perhaps the biggest problem, in my case, is that most of the things I want to do with it are kind beyond my ability to realize, when I first dream them up. However, in my defense, the "little boxes" dimension of Max (i.e., Max as an application) makes my ideas seem achievable, whereas the underbelly of Max (i.e., the scheduler, queue, threads - Max as an IDE) sometimes drops the reality down squarely on my head. That's the best I can do to explain my situation, and I've already said too much.
J.
Ok, that's interesting. It seems like there are a lot of people screaming that stuff doesn't work correctly while they don't know what it is supposed to do, hence my question. (btw I understand the screaming, but it shouldn't be about the system but about lack of documentation or perhaps about max not meeting their expectations in general, as I said earlier in this thread).
But since you are aware of the supposed behaviour, I've been thinking about what you could possibly mean with a backlog problem. I personally didn't find any issues with the scheduler. Of course there will be backlog if your cpu can't cope with the amount of events, but that is expected behaviour, right? Or do you mean that the permitted slop doesn't work correctly? Or do you expect max to use the cpu more efficient and handle more events? It would be great if you were able to make a patch that demonstrates the issues you encounter.
Btw, cycling 74, there is a typo in the Scheduler slop 'About' in Performance options: "Typcially some amount of slop is desired so that.."
Cheers,
Mattijs
Quote: jbm wrote on Tue, 20 March 2007 16:11
----------------------------------------------------
> Quote: Mattijs wrote on Tue, 20 March 2007 14:22
> ----------------------------------------------------
> > Just curious: do (you think) you know exactly how the scheduler works? E.g. did you read jkc's article about threading in max?
> >
> > - Mattijs
> >
>
> I do "think" I know how the scheduler works, and yes I've read that article, and pretty much every other description of it I've found over the past 10 years. In fact, I just read it again, and I can say the same thing I said the last time I read it: what appears to be happening whenever I kill the scheduler is event backlog. Unfortunately, these are not patches that can accept any kind of speedlim procedure, since all the messaging that's going on is in some way essential to the process. Is it a case of bad or just overly-ambitious programming on my part? Quite possibly. On the bright side, my most recent project has enjoyed a great improvement in stability by a minor redesign which greatly reduced the number of messages crossing the max/java bridge. What can I say? I try. Perhaps the biggest problem, in my case, is that most of the things I want to do with it are kind beyond my ability to realize, when I first dream them up. However, in my defense, the "little boxes" dimension of Max (i.e., Max as an application) makes my ideas seem achievable, whereas the underbelly of Max (i.e., the scheduler, queue, threads - Max as an IDE) sometimes drops the reality down squarely on my head. That's the best I can do to explain my situation, and I've already said too much.
>
> J.
----------------------------------------------------
Quote: Mattijs wrote on Tue, 20 March 2007 16:30
----------------------------------------------------
> Ok, that's interesting. It seems like there are a lot of people screaming that stuff doesn't work correctly while they don't know what it is supposed to do, hence my question. (btw I understand the screaming, but it shouldn't be about the system but about lack of documentation or perhaps about max not meeting their expectations in general, as I said earlier in this thread).
>
> But since you are aware of the supposed behaviour, I've been thinking about what you could possibly mean with a backlog problem. I personally didn't find any issues with the scheduler. Of course there will be backlog if your cpu can't cope with the amount of events, but that is expected behaviour, right? Or do you mean that the permitted slop doesn't work correctly? Or do you expect max to use the cpu more efficient and handle more events? It would be great if you were able to make a patch that demonstrates the issues you encounter.
>
Well, my cpu is a G5 dual 1.8, and I'm just dealing with midi data, so I'm always a bit stumped when I run into problems. Coincidentally, I've just had a quick exchange of dialog with a friend who does similar work to myself, and who has similar backlog problems in Max. It turns out that he's been able to solve the majority of his issues with the liberal use of deferlows. Of course, this implies that the issue was thread related, not necessarily backlog... or maybe it's some sort of backlog happening on the high-priority thread? Not sure. Anyway, it was encouraging. I know I've managed to solve some of my problems in the past with deferlows. But in those cases it followed logically as a possible solution. My more recent problems don't appear to be related. Anyway, part of the reason I also mentioned the more detailed debugging system is that I don't honestly know with absolute certainty that backlog is the issue. I suspect it is, but I don't know for certain. But, in my experience, when Max gets the spinning ball, then quits, it's usually backlog.
I'm heading out of town for a couple of weeks - a *much* needed break - so perhaps I'll return with a clear(er) head and work these problems out. If I can't solve it, I'll definitely try to make a patch to demonstrate.
cheers,
J.
>>part of the reason I also mentioned the more detailed debugging
>>system is that I don't honestly know with absolute certainty that
>>backlog is the issue.
FWIW, this is one of the things we have been discussing as a potential
aspect of the Max 5 trajectory.
Cheers,
Andrew B.
Quote: andrewb@cycling74.com wrote on Tue, 20 March 2007 18:36
----------------------------------------------------
> FWIW, this is one of the things we have been discussing as a potential
> aspect of the Max 5 trajectory.
>
> Cheers,
> Andrew B.
>
----------------------------------------------------
Boy, I have sooo much ideas about this. But you guys probably have enough ideas to consider.
Mattijs
Ok, just to make sure I understand: you don't think something is wrong with the scheduler, the backlog probably makes sense in your situation but there is no real way for you to find out.
I agree about that. To find bugs or sort out strange behaviour I currently spend -a lot- of time making all sort of strange patches, solely to find out why an object or combination of objects behave as they do.
Sometimes I wonder, will Cycling '74 go the same way as Macromedia, with Flash? First they make a nice tool which fills a gap in the market but is no serious development tool. Slowly it appears that people take the whole thing pretty serious and to make the concept complete, more control and flexibilty is needed so they invest in actionscript. After a while the gap in the market appears to be much bigger than they anticipated (developers start using it as a main development tool for projects where big cash is involved), so actionscript suddenly needs to match some deadly serious requirements to satify the needs of the increasing amount of pro users, even though the original aim wasn't even close to this trajectory. Now (only just in actionscript 3!!), they include the 'strict' mode, a mega-essential feature for the huge professional userbase that in the meanwhile came into existence. This means that for the first time since Flash was born, debugging became a serious matter.
Funny, eh?
Mattijs
Quote: jbm wrote on Tue, 20 March 2007 17:44
----------------------------------------------------
> Well, my cpu is a G5 dual 1.8, and I'm just dealing with midi data, so I'm always a bit stumped when I run into problems. Coincidentally, I've just had a quick exchange of dialog with a friend who does similar work to myself, and who has similar backlog problems in Max. It turns out that he's been able to solve the majority of his issues with the liberal use of deferlows. Of course, this implies that the issue was thread related, not necessarily backlog... or maybe it's some sort of backlog happening on the high-priority thread? Not sure. Anyway, it was encouraging. I know I've managed to solve some of my problems in the past with deferlows. But in those cases it followed logically as a possible solution. My more recent problems don't appear to be related. Anyway, part of the reason I also mentioned the more detailed debugging system is that I don't honestly know with absolute certainty that backlog is the issue. I suspect it is, but I don't know for certain. But, in my experience, when Max gets the spinning ball, then quits, it's usually backlog.
>
> I'm heading out of town for a couple of weeks - a *much* needed break - so perhaps I'll return with a clear(er) head and work these problems out. If I can't solve it, I'll definitely try to make a patch to demonstrate.
>
> cheers,
>
> J.
----------------------------------------------------
On Mar 20, 2007, at 2:58 PM, Mattijs Kneppers wrote:
>
> Ok, just to make sure I understand: you don't think something is
> wrong with the scheduler, the backlog probably makes sense in your
> situation but there is no real way for you to find out.
>
> I agree about that. To find bugs or sort out strange behaviour I
> currently spend -a lot- of time making all sort of strange patches,
> solely to find out why an object or combination of objects behave
> as they do.
>
> Sometimes I wonder, will Cycling '74 go the same way as Macromedia,
> with Flash? First they make a nice tool which fills a gap in the
> market but is no serious development tool. Slowly it appears that
> people take the whole thing pretty serious and to make the concept
> complete, more control and flexibilty is needed so they invest in
> actionscript. After a while the gap in the market appears to be
> much bigger than they anticipated (developers start using it as a
> main development tool for projects where big cash is involved), so
> actionscript suddenly needs to match some deadly serious
> requirements to satify the needs of the increasing amount of pro
> users, even though the original aim wasn't even close to this
> trajectory. Now (only just in actionscript 3!!), they include the
> 'strict' mode, a mega-essential feature for the huge professional
> userbase that in the meanwhile came into existence. This means that
> for the first time since Flash was born, debugging became a serious
> matter.
>
> Funny, eh?
>
> Mattijs
I for one, would love this sort of trajectory...
v a d e //
www.vade.info
abstrakt.vade.info
> This means that for the first time since Flash was born, debugging
became a serious matter.
I believe that this is _exactly_ what has happened with Max - it has
evolved to a point that I'm sure was never imagined.
Without a doubt, its the best tool to prototype and develop interactive
systems. But many of us are so comfortable in Max, that we are using
it to build systems that were formerly the domain of procedural
languages.
And I guess we're asking for some of the tools that those languages
have...
> Coincidentally, I've just had a quick exchange of dialog with a
> friend who does similar work to myself, and who has similar
backlog
> problems in Max. It turns out that he's been able to solve the
> majority of his issues with the liberal use of deferlows.
Hey, that would be me!
Not being a "real" programmer, I can't profess to understand the
scheduler completely. But what I can infer is that events triggered
by a bang operate at some sort of an interupt level. Unlike audio, a
fixed number of Max instructions are not pre-scheduled, so when
the instructions pile up and other matters cannot be attended, Max
coughs (the stack overflow dialog, or worse, the dreaded spinning
ball).
By putting the defer or deferlow object in strategic places, I've
avoided both.
In the example below, note that the left part causes a stack
overflow, whereas the right one does not.
This is probably old news to most people....
in regards to error debugging...., part of the beauty of debugging in max is that is almost exclusively manual. it really makes you mentally visualize your flow and think about what's going wrong. I don't know why anyone would want otherwise. But i realize I'm probably the minority here.
just say no to brainless over-efficiency.
Erm.
You are creating a feedback loop there on the first one. Thats your
problem : throw in a delay, or a pipe, or something, I think the
deferlow there 'fixing' it is more of a fluke and not appropriate (at
least in my somewhat inadequate understanding of the scheduler
underpinnings).
On Mar 20, 2007, at 4:06 PM, Arne Eigenfeldt wrote:
>
>> Coincidentally, I've just had a quick exchange of dialog with a
>> friend who does similar work to myself, and who has similar
> backlog
>> problems in Max. It turns out that he's been able to solve the
>> majority of his issues with the liberal use of deferlows.
>
> Hey, that would be me!
>
> Not being a "real" programmer, I can't profess to understand the
> scheduler completely. But what I can infer is that events triggered
> by a bang operate at some sort of an interupt level. Unlike audio, a
> fixed number of Max instructions are not pre-scheduled, so when
> the instructions pile up and other matters cannot be attended, Max
> coughs (the stack overflow dialog, or worse, the dreaded spinning
> ball).
>
> By putting the defer or deferlow object in strategic places, I've
> avoided both.
>
> In the example below, note that the left part causes a stack
> overflow, whereas the right one does not.
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P comment 260 53 57 196617 Happiness!;
> #P newex 264 135 50 196617 deferlow;
> #P button 264 78 15 0;
> #P newex 264 160 20 196617 t b;
> #N counter;
> #X flags 0 0;
> #P newobj 264 107 66 196617 counter;
> #P button 168 78 15 0;
> #P newex 168 160 20 196617 t b;
> #N counter;
> #X flags 0 0;
> #P newobj 168 107 66 196617 counter;
> #P comment 152 52 82 196617 Stack overflow!;
> #P connect 1 0 2 0;
> #P fasten 5 0 4 0 269 184 249 184 249 103 269 103;
> #P connect 6 0 4 0;
> #P connect 7 0 5 0;
> #P connect 4 0 7 0;
> #P connect 3 0 1 0;
> #P fasten 2 0 1 0 173 184 153 184 153 100 173 100;
> #P window clipboard copycount 9;
>
> This is probably old news to most people....
v a d e //
www.vade.info
abstrakt.vade.info
being able to set breakpoints or to have trace selectively triggered
would be a welcome addition. That is not brainless or over-efficient,
it is a functional addition that every other programming environment
has had since the inception of programming. (not a rag on max btw,
just a statement)
On Mar 20, 2007, at 4:13 PM, jamez wrote:
>
> in regards to error debugging...., part of the beauty of debugging
> in max is that is almost exclusively manual. it really makes you
> mentally visualize your flow and think about what's going wrong. I
> don't know why anyone would want otherwise. But i realize I'm
> probably the minority here.
>
> just say no to brainless over-efficiency.
v a d e //
www.vade.info
abstrakt.vade.info
On 20 mars 07, at 21:06, Arne Eigenfeldt wrote:
> This is probably old news to most people....
I won't say that second version *works*, even if by "works" you mean
it doesn't crash. I mean if you really want to count as fast as
possible, [uzi] is the object made for that. In normal life, you'll
quite never have to use [deferlow].
ej
It's not a feedback loop, but an infinite counter. Why shouldn't it work - I'm simply asking the computer to count as high as it can, as fast as it can?
The second version doesn't change that - it simply allows Max to "take a breath" while counting.
Obviously, one would never use deferlow in such a case - it's simply a simple demonstration (to my mind) on how it can stop Max from choking.
Quote: arne wrote on Tue, 20 March 2007 21:06
----------------------------------------------------
> But what I can infer is that events triggered
> by a bang operate at some sort of an interupt level. Unlike audio, a
> fixed number of Max instructions are not pre-scheduled, so when
> the instructions pile up and other matters cannot be attended, Max
> coughs (the stack overflow dialog, or worse, the dreaded spinning
> ball).
I.. don't think this is what jbm's problem is about. Have a look at the in-depth article about queue and scheduler to find out more. It's really interesting info even if you're not a programmer.
I'm afraid there is more to this than liberally placing deferlows, jbm..
Mattijs
>
> By putting the defer or deferlow object in strategic places, I've
> avoided both.
>
> In the example below, note that the left part causes a stack
> overflow, whereas the right one does not.
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P comment 260 53 57 196617 Happiness!;
> #P newex 264 135 50 196617 deferlow;
> #P button 264 78 15 0;
> #P newex 264 160 20 196617 t b;
> #N counter;
> #X flags 0 0;
> #P newobj 264 107 66 196617 counter;
> #P button 168 78 15 0;
> #P newex 168 160 20 196617 t b;
> #N counter;
> #X flags 0 0;
> #P newobj 168 107 66 196617 counter;
> #P comment 152 52 82 196617 Stack overflow!;
> #P connect 1 0 2 0;
> #P fasten 5 0 4 0 269 184 249 184 249 103 269 103;
> #P connect 6 0 4 0;
> #P connect 7 0 5 0;
> #P connect 4 0 7 0;
> #P connect 3 0 1 0;
> #P fasten 2 0 1 0 173 184 153 184 153 100 173 100;
> #P window clipboard copycount 9;
>
> This is probably old news to most people....
>