radiotonga

Hello, I wanted to know if the message order scheme that goes with Max objects (right-to-left, bottom-to-top) applies to MSP objects. I know that on a sample-rate basis this might not be of any relevance, but I've always been curious if this thing actually applies to MSP.

msp-object-message-ordering

No. All signal/MSP objects send samples out their outlets at same time(this is how working in the signal realm can be so 'sample-accurate'). (You're correct, right-to-left ordering isn't relevant for signal outlets.)

Thanks Raja. Just out of curiosity though, at the lowest level (microprocessor), are these samples actually being triggered at the same "quantum" time? I mean, all these sample computations are being done at the same 1000ms/sample-rate point in time, right?

Also, my guess would be that the Gen object operates on the same logic, right? Then the difference between Gen objects and regular MSP objects would be that since they are encoded at a lower level they are more efficient to work on that same sample rate basis. I say this because I've read that Gen appeared as a workaround to the inherent difficulties some MSP objects have on working on a per-sample basis.

Thanks Raja. Just out of curiosity though, at the lowest level (microprocessor), are these samples actually being triggered at the same "quantum" time? I mean, all these sample computations are being done at the same 1000ms/sample-rate point in time, right? 

Also, my guess would be that the Gen object operates on the same logic, right? Then the difference between Gen objects and regular MSP objects would be that since they are encoded at a lower level they are more efficient to work on that same sample rate basis. I say this because I've read that Gen appeared as a workaround to the inherent difficulties some MSP objects have on working on a per-sample basis.


are these samples actually being triggered at the same "quantum" time?

'triggered', yes(as long as the audio-engine can handle all processes and is not choking).

I mean, all these sample computations are being done at the same 1000ms/sample-rate point in time, right?

'computations'... not exactly... internally speaking, an msp process or external, grabs a vector's worth of input samples at a time(this is the 'signal vector' size set within 'AudioOptions...'), computes/calculates math on all the samples as fast as the computer's cpu/microprocessor can handle(much much faster than sample rate), then passes this vector on to the audio chain which can then output samples from that vector, one-by-one reliably at sample-rate.

it gets a bit technical, i'm not sure i can explain it completely or well, but basically, (while the cpu can handle it and the audio engine is not choking) you can trust the signals passed between every msp external to carry samples calculated for the same sample-accurate point in time.

(ugh... i've not explained well... and i think a logical next question based on my confusing words might be "does that mean each msp external adds a vector's worth of delay?" and the answer is 'no, the vector of delay generally applies to the total audio chain(certain objects like pfft~, etc. will add more depending on settings and needs)' but i am too scatter-brained in my learning this stuff(

Then the difference between Gen objects and regular MSP objects would be that since they are encoded at a lower level they are more efficient to work on that same sample rate basis.

ah! sort of... but this helps me explain it better... ideally, a gen~ object that replicates a regular msp object exactly would work with the same exact efficiency. but because msp objects work on vectors of samples at a time, while gen~ can work sample-by-sample, it allows devs to work with more sample-accurate detail without having to code the math in c for an msp external(wherein, you'd work within a c function called the object's "perform method", and this is where, although the method gets passed a vector's worth of samples at a time, you could specify what happens to each sample individually within that vector)

I say this because I’ve read that Gen appeared as a workaround to the inherent difficulties some MSP objects have on working on a per-sample basis.

Yes, essentially that is correct(to understand this fully, i'd recommend studying how msp externals are written at the c level from the 

But 'efficiency' and 'sample-by-sample' calculation are different things generally speaking... gen~ coded poorly, verbosely, inefficiently, will be inefficient no matter what... i do this myself often, simply because gen~ still gets me to see the 'sample-by-sample' math more clearly, but learning in that context can also help you detect ways to improve efficiency more easily and with more detail.

The benefit of gen~ is mostly a matter of being able to be 'sample-by-sample' specific(while adding some flexibility in terms of combining a coding way(codebox/genexpr) with a visual patching way, as well as adding the benefit of being able to output code for other things outside of max entirely).

The benefit of 'efficiency' comes more with DSP/programming skill and experience(whether you use gen~ or regular msp objects).

'computations'... not exactly... internally speaking, an msp process or external, grabs a vector's worth of input samples at a time(this is the 'signal vector' size set within 'AudioOptions...'), computes/calculates math on all the samples as fast as the computer's cpu/microprocessor can handle(much much faster than sample rate), then passes this vector on to the audio chain which can then output samples from that vector, one-by-one reliably at sample-rate.
it gets a bit technical, i'm not sure i can explain it completely or well, but basically, (while the cpu can handle it and the audio engine is not choking) you can trust the signals passed between every msp external to carry samples calculated for the same sample-accurate point in time.

Yes, essentially that is correct(to understand this fully, i'd recommend studying how msp externals are written at the c level from the sdk).
But 'efficiency' and 'sample-by-sample' calculation are different things generally speaking... gen~ coded poorly, verbosely, inefficiently, will be inefficient no matter what... i do this myself often, simply because gen~ still gets me to see the 'sample-by-sample' math more clearly, but learning in that context can also help you detect ways to improve efficiency more easily and with more detail.

The benefit of 'efficiency' comes more with DSP/programming skill and experience(whether you use gen~ or regular msp objects).


Thanks again man, apart from the questions I asked you have touched a ton others that were in queue (vector size, efficiency issues, fft~, etc.) My guess would be that vector size, upsampling (until poly~) and Max's inability to work on a per-sample basis were some of the culprits for that old debate regarding Max audio quality vs other DSP software (SuperCollider, for instance). As I understand it, working with chunks of samples (vectors) could potentially bring discontinuities and artefacts to the audio chain, apart from bringing some (unnoticeable) latency/delay, but this is way out of my league and you have already cleared this up a bit.

Now I'm gonna read up again those introductory documents in the MSP Tutorials, and then ask some more questions :p

Thanks again man, apart from the questions I asked you have touched a ton others that were in queue (vector size, efficiency issues, fft~, etc.) My guess would be that vector size, upsampling (until poly~) and Max's inability to work on a per-sample basis were some of the culprits for that old debate regarding Max audio quality vs other DSP software (SuperCollider, for instance). As I understand it, working with chunks of samples (vectors) could potentially bring discontinuities and artefacts to the audio chain, apart from bringing some (unnoticeable) latency/delay, but this is way out of my league and you have already cleared this up a bit. 

Now I'm gonna read up again those introductory documents in the MSP Tutorials, and then ask some more questions :p


Max audio quality vs other DSP software (SuperCollider, for instance).

ah, SuperCollider! haha, ya, i've heard about those comparisons and since i'm an sc user myself, i might have some more answers there too...

As I understand it, working with chunks of samples (vectors) could potentially bring discontinuities and artefacts to the audio chain

everything in digitalaudio needs to work in chunks anyways(like hardware 'buffersize').

audio quality in different software depends more on the proprietary/custom algorithms that happen in actual processing functions(where the input is changed in some way)... but generally speaking, and especially these days, most audio environs should at least pass audio from inputs to outputs in the same/similar way and vector size doesn't matter too much(choosing a smaller vector size can tax the system more, and may cause errors in that way, but this will be a problem common to all environs).

supercollider and pd(by default) both act the same as max if max were set to vector size of 64 and both 'overdrive' and 'in audio interrupt' were turned on in 'audio options'(max often starts by default with a larger vector size setting and with those other settings turned off i think... this can cause a crucial first point of confusion for sc and pd users).

supercollider also has some under-the-hood antialiasing and interpolation schemes that make certain UGens sound better by default(in max, you need to add these things in, or know about how to access them via attributes and messages...).

and finally, one crucial difference i've noticed but can't explain well because this is also at a lower-level than i generally understand, supercollider runs things by default in fewer 'threads'(for example 'TempoClock' in SC starts by default operating in the main thread, and you have to explicitly tell it to operate in a separate thread if you want that...) which can help keep timing tighter in supercollider(an example of this would be hard to come by since we don't know how everything in max(like poly~) is coded internally, but... more as a poke in the general direction: the reaction time for dynamic voice-allocation in poly~ seems less reliable than the reaction time for similar voice-allocation on an sc server(while max has the same audio/scheduler settings mentioned above to match it to sc behavior) which leads me to believe, that in general, the server architecture is tighter in its audio-to-control-rate and vice-versa synchronization... and the only thing i've ever read on nabble forums somewhere that seemed to come close to explain it, was something that explained a bit on how sc handles 'threads'... can't find it now :p).

anyways, sorry i can't explain everything very well... but hopefully that points you in some good directions for your own further research.

everything in digitalaudio needs to work in chunks anyways(like hardware 'buffersize').
audio quality in different software depends more on the proprietary/custom algorithms that happen in actual processing functions(where the input is changed in some way)... but generally speaking, and especially these days, most audio environs should at least pass audio from inputs to outputs in the same/similar way and vector size doesn't matter too much(choosing a smaller vector size can tax the system more, and may cause errors in that way, but this will be a problem common to all environs).

anyways, sorry i can't explain everything very well... but hopefully that points you in some good directions for your own further research.


I think the larger argument was the claim that "Reaktor sounds better than Max/MSP." There were two things to note here.

First, Reaktor does make its calculations sample-by-sample (rather than in blocks of samples or "sample vectors"). The immediate result of this is that MSP can, generally, manage slightly more complicated patch constructions with the same CPU horsepower (as a rule of thumb, the smaller the size of the sample vector--in any DSP software--the more overhead per sample and the more CPU processing needed to calculate the same dataflow). This doesn't really have any effect on quality of sound, however.

But I am pretty sure (and this would be the more important point) that NI also does a bit of general signal tweaking between the output of a signal chain and the DAC, with the goal of getting a "good sound." MSP, otoh, just does what it says on the tin. If you want a "phatter" (or thinner, or thicker, or whateverer) sound, you have to program it yourself. The OMX objects, btw, can be useful tools in this regard.

I'm not sure if SC does any general signal tweaking. My understanding is that the software is, in a number of ways, more efficient that MSP, and that was its main advantage.

I was initially told that the reason for the particular "transparency" [I hate those golden ears audio terminology rabbit holes, but this will have to do] that Supercollider manages - particularly in those situations where one is working with multiple samples overlaid and offset by a small number of samples - is directly related to the dithering (and interpolation?) algorithms it uses. Although my memory could certainly be faulty, my recollection is that comment emerged in the course of a cordial and enjoyable luncheon with Mr. McCartney himself and a number of Supercollider microstars. I could certainly be wrong, but I don't think so.

If that *is* so, some clever person could go rooting around in the Supercollider code and perhaps identify what said algorithms *are*, and then attempt to apply them in the gen~ per-sample themepark. It won't be me, since I am currently trying to recover all the things about Max knob-fu on an ARC4 that I appear to have entirely forgotten [a sort of loss of memory that does not, in my case, work the way it does on telenovellas, where a single incident can apparently trigger the recovery of ALL the lost memories].

[a sort of loss of memory that does not, in my case, work the way it does on telenovellas, where a single incident can apparently trigger the recovery of ALL the lost memories]

But those telenovelas have ALL the answers, are you sure you've tried all the telenovela possibilities?

-smell the teak oil finish of the arc4 til you pass out and fall through the looking glass into wonderland

-look at old photos of back when you and the arc4 went for a romantic ferry ride on the Seine

-invite that one person over for tea who seemed to hate your arc4 the most and flaunt it in front of them the whole time until they are so maddened by the sight that they end up unwittingly revealing their plot of erasing your memories(but only those relating to the arc) in order to make you look like a fool in front of your arc so that the arc would leave you for them

Don't give up on the formulas of melodrama!

But those telenovelas have ALL the answers, are you sure you've tried all the telenovela possibilities?
For example:
-hit yourself on the head with the arc4
-smell the teak oil finish of the arc4 til you pass out and fall through the looking glass into wonderland
-look at old photos of back when you and the arc4 went for a romantic ferry ride on the Seine
-invite that one person over for tea who seemed to hate your arc4 the most and flaunt it in front of them the whole time until they are so maddened by the sight that they end up unwittingly revealing their plot of erasing your memories(but only those relating to the arc) in order to make you look like a fool in front of your arc so that the arc would leave you for them

Don't give up on the formulas of melodrama!


I'm hoping I can bring this topic back. A short coming I've always seen with msp is that there's no equivalent to function pointers, it's hard to build modular systems. I DID notice that poly~ now incurs no delay? (When did that happen!?)

Anyway I I found a way to build mod matrices in gen by using peek and poke. Then I realized that the reason I assumed I couldn't in MSP was a test I did in max 4.6!!!

So I'm wondering if anything has changed in the interim where I could predict the ordering of peeking and poking. Obviously it matters because you wouldn't wanna write to memory after you've read it.

I'm hoping I can bring this topic back.  A short coming I've always seen with msp is that there's no equivalent to function pointers, it's hard to build modular systems.    I DID notice that poly~ now incurs no delay?  (When did that happen!?) 

Anyway I I found a way to build mod matrices in gen by using peek and poke.  Then I realized that the reason I assumed I couldn't in MSP was a test I did in max 4.6!!!

So I'm wondering if anything has changed in the interim where I could predict the ordering of peeking and poking. Obviously it matters because you wouldn't wanna write to memory after you've read it. 

MSP object message ordering