MSP fundamentals

Jun 02 2009 | 4:40 pm

Hya,

i have a few MSP related question still worrying me after greping google, manuals, forum and tutorial.

I understand that the MSP signal (audio, ~, yellow cables)is a consecutive stream of values flowing (or changing) at a constant rate.

- What is the datatype of one value (sample) in that signal? - size, range? - resolution, precision?

All i know from working with it, it seems to be able to represent quite big values, but on the other hand needs at least a 16bit resolution in the range from -1 to 1. because the adc~ and dac~ and in general audio signals seem to be representes as between -1 and 1, as usual. But in contrast a signal value is used as index to a buffer, and therefore i expect the signal to be able to represent a quite large integer number.

How does Max handle this paradoxon?

does the internal resolution between -1 and 1 change when the audio driver delivers samples in 16,24,or 32bit?

how is this handled?

I hope anyone can give some clearing facts, or can point me to a documentation where these topics are being adressed.

Thanx in advance! Cheers HEck

Jun 02 2009 | 4:42 pm
heck
Is the maximum buffer~ size the the size of a msp signal? how do you adress larger buffers than a signal can adress?
Share
Jun 02 2009 | 9:45 pm
Rui Caldas
Hi
You can use any number in "signal mode"
try this:
floatnumber box >> sig~ >> number~
As yiou can see, the number is what you put there!
But to send signals to the speakers, you have to be careful, because if you send an signal of 15. to the speakers, you can burn them!
The resolution depends on the DSP configuration.... audio card settings Ex.: 44100Hz 16Bit And there are the IO vector size and signal vector size, witch is the number of samples in every pack tha CPU process, if I'm not wrong.
If I'm no wrong again, every sample with 16Bit has info like this "0011011011001001" that means the "level" of the signal at that precise moment!
note: Sorry guys that are loling rigth now!
Don't forget: this "1" is diferent from this "1.", and signals are "floating numbers"
Share
Jun 02 2009 | 9:57 pm
Rui Caldas
Hi again
Signals are used to represent sound waves, and waves are made of several values/time. Try to see your wave like a sequence of many points in an grid, where Hz are the number of columns/second and Bit rate the number of lines from -1. to 1.
The resolution of your wave is the Bit depth and the sampling frequency.
And don't forget, 16 bit has 65536 steps (lines)
2 possibilities (0 or 1) power 16 (number of 0s and 1s in a "word") 2 power 16 = 65536
Share
Jun 02 2009 | 10:37 pm
Roman Thilenius
Rui Caldas wrote on Tue, 02 June 2009 23:57
You can use any number in "signal mode"
As yiou can see, the number is what you put there!
But to send signals to the speakers, you have to be careful, because if you send an signal of 15. to the speakers, you can burn them!
The resolution depends on the DSP configuration.... audio card settings Ex.: 44100Hz 16Bit
The resolution of your wave is the Bit depth and the sampling frequency.
And don't forget, 16 bit has 65536 steps (lines)
2 possibilities (0 or 1) power 16 (number of 0s and 1s in a "word") 2 power 16 = 65536
if that is a joke, this would be the first time that i dont get someones joke in the max forum.
usually it is the other way round.
-110
Share
Jun 02 2009 | 10:47 pm
kjg
heck wrote on Tue, 02 June 2009 18:40 - What is the datatype of one value (sample) in that signal? - size, range? - resolution, precision?
32 bit float
Share
Jun 05 2009 | 9:58 am
heck
Hya,
Kjg, Thank you!
seems like there are people being even more confused than i was.
so, MSP signal sample - signed 32 bit float, that means 24 bit precision.
Share
Jun 10 2009 | 6:41 pm
heck
patch is so tiny, not worth posting
the float seems to be a "32 bit signed float" and it doesnt wrap around
A Signal tough, seems to be able to represent more than 32bits. Ok, must be 64bit float one may think, but who _knows_ what it is? how this is implemented? could theoretically be everything..
i'll grep the externals SDK once again
Share

Jun 10 2009 | 7:13 pm

This is what i found in z_dsp.h

The sample definition:

#ifndef SAMPLE_TYPEDEF
typedef int t_int;
typedef float t_sample, t_float;
#define SAMPLE_TYPEDEF
#endif

yep t_sample is a float.

typedef struct _signal
{
    long s_n;
    t_sample *s_vec;
    float s_sr;
    struct _signal *s_next;
    struct _signal *s_nextused;
    short s_refcount;
    short s_size;
    char *s_ptr;
} t_signal;

_signal looks like a linked list, to me. but I still dont get the picture.

Jun 10 2009 | 8:39 pm
Roman Thilenius
heck wrote on Wed, 10 June 2009 20:41patch is so tiny, not worth posting
A Signal tough, seems to be able to represent more than 32bits. Ok, must be 64bit float one may think, but who _knows_ what it is? how this is implemented? could theoretically be everything..
this numbox with the 159753606382222336 in it is what i would call a signum bug.
i have seen numberboxes (for signal as well as number) with numbers of 50 and more digits. but it is a fata morgana, nothing else.
dont trust numberboxes! they tend to tell fairy tales.
but i must say i am bit confused about the [snapshot~] behaviour we see here.
-110
Share
Jun 11 2009 | 2:29 pm
heck
Quote: this numbox with the 159753606382222336 in it is what i would call a signum bug.
I see no indication that this is a bug in the [signum~] But what i see is that the [snapshot~] does completely agree with [signum~]. So, then they both would need have the same bug, rendering both objects useless in this circumstance.
Quote: i have seen numberboxes (for signal as well as number) with numbers of 50 and more digits. but it is a fata morgana, nothing else.
What makes you not believe what you see?
Quote: dont trust numberboxes! they tend to tell fairy tales.
exactly, i didnt trust the [signum~], that why i put in the [snapshot~]-[print]. They agree, so to my logical completion of your advise is to not trust the [snapshot~] as well.
Final question: What can i trust then?
Quote: but i must say i am bit confused about the [snapshot~] behaviour we see here.
I am confused about the internals of MaxMSP completely.
It would really make the product so much more valuable, if one could get logical explanations for an observation like this.
Share
Jun 11 2009 | 4:00 pm
Peter Castine
There has been a lot of confusion in this thread, not to mention some misinformation.
heck wrote on Tue, 02 June 2009 18:40I understand that the MSP signal (audio, ~, yellow cables)is a consecutive stream of values flowing (or changing) at a constant rate.
- What is the datatype of one value (sample) in that signal? - size, range? - resolution, precision?
This information is all in the tutorials & reference manual. The point is not RTFM, but that you can confirm the following from those sources.
A signal in MSP is a stream of 32-bit floating point values at the current sample rate (often 44.1kHz, but whatever is set in the DSP Options, and inside a poly~ factor in any up/downsampling).
Range: according to IEEE 754, 32 bit floats have a enormous range that you will probably never use ("probably never use" == "probably never have clipping artifacts"), approx ±3.4028235 × 10^38.
However, adc~ will only ever give you an input in the range [-1 .. 1]; dac~ will clip output to that same range. This is the "canonical" range for signals.
You are free to go outside the unit range in intermediary calculations. But you should remind yourself that this is floating point.
If you know what floating point implies, that will answer your question regarding resolution. Else you need to run not walk to What Every Computer Scientist Should Know About Floating-Point Arithmetic. Peter Elsea has also written a helpful tutorial, and the Wikipedia articles on IEEE 754 are informative. They should clarify the misconceptions about flonum or signum~ being unreliable (they aren't, they're just limited to IEEE 754 capabilities). The really cool kids will also have read The pitfalls of verifying floating-point computations
Also, the struct definition of _signal inside the MSP SDK is irrelevant to this question and will confuse more than help. That is related to how MSP passes data between objects in the DSP network. There is much more involved beyond a stream of 32-bit floats.
Share
Jun 12 2009 | 12:46 am
Roman Thilenius
heck wrote on Thu, 11 June 2009 16:29
I see no indication that this is a bug in the [signum~] But what i see is that the [snapshot~] does completely agree with [signum~]. So, then they both would need have the same bug, rendering both objects useless in this circumstance.
signum~ is an opportunist!
he would kill babies if you tell him to!
the number 159753606382222336 will be useless in max under _any circumstances.
do you see that other number in your patch which begins with 217 something? try to find out why it shows this number and not the one from the signum and you will know what i mean.
or try typing "159753606382222336" into a messagebox and make a copy of it.
another hint: get [printit] from maxobjects.com and use it side by side with [print]. [print] made me learn a lot about maxmsp (and the print object) in the past, and still helps me today when developing stuff.
Quote: Final question: What can i trust then?
it is all unsure. we never know.
the only thing you can usually trust here is peter castine.
when he explains the term "signal" by saying it is a "stream", you of course still dont know what it is - but you can at least trust the source of information.
-110
Share