Why dont maths operators output floating point numbers?
I just don't get this, maths is good but only if you work with whole numbers? I was told previously that if you put a "f" object after a maths operation it outputs from the f a floating point integer, but what's the point in that if maxmsp has already rounded up/down the number to a whole? :s
Case example:
The slider range is 0 to 100, the greenish box should be showing a number between -1 and 1 depending on where you set the slider. Sadly, float values only look designed to be made by the "user".
Max Tutorial 6 is called "Simple Math in Max":
[- ] [+ ] [/ ] etc work with integers and output integers.
[- 0.] [+ 0.] and such output floats.
Talk about following the m25 to get into london! Why not just make the + - / * objects handle BOTH? Seriously it seems totally anal to have a seperate object for each, and doesn't indeed serve any purpose. I still dont believe the tutorials/help files are correct. In fact, i think i've proved it... check this code out:
The upper keyboard octave works perfectly, no problems at all! But the lower octave, unless it's set to 5, will play the acutal note, and the fifth octave note too. BUT BUT BUT! ....the object layouts for both of them are exactly the same!
Crinkle wrote on Sun, 19 July 2009 00:12
Why not just make the + - / * objects handle BOTH?
because
1.)
that would require a lot more CPU.
a [+] object which can handle both, int and float, would
have to do a type check for every input, and then eventually
switch its mode on the fly when another type comes in.
2.)
there is also an additional problem with it: you would no
longer be able to perform a float-operation and -output
on an int number or the other way round.
a [+] object which is int-only will truncate incoming
floats. this is something you will need all the time.
if it could handle float mode automatically according to
input type, one would need to do "7.5" [i] [+], which is
more work and needs more CPU.
it is also true the other way round: it is absolutely possible
to use [+ 0.] to add ints, they just come out as floats like
"77.0", but thats not a problem as those are truncated to 77
in other objects in int mode. the calculation remains correct.
...only for / or √ there is a difference, of course. but who
wants a truncated or rounded / or √ output? except for
graphics, text, or tables, the integer result of 5/7 is
really useless.
Quote:
Seriously it seems totally anal to have a seperate object for each, and doesn't indeed serve any purpose.
[+ 0.] or [line 0.] are not seperate objects, the 0. is
just an argument.
you can do [+ 5.] too in order to get float mode.
in most situations when programming max (or java or C or
whatever) you will define a default operand anyway.
"plus one" or "plus one float" is far more often used than
"plus variable" - in every programming language.
to make a difference between LONG and 32 bit floating point
is standard.
if you attach the patch about your wrong helpfiles i can
look at at it with my maxmsp v4 and will answer this, too.
-110
.
I'm not sure what it is about the patch you posted that doesn't work as expected, and I don't want to seem patronising or anything, but I think it's always best to assume that when something doesn't work how you thought it would, that you've made a mistake or misunderstood something along the way.
Happens to me all the time - just make sure that when it happens you learn from it rather than getting frustrated.
If you were a little more specific about what isn't working how you thought I might be able to help, although I think RT etc. could give you a better answer - I still consider myself a beginner.
What's wrong as i said is that playing the upper keyboard octave is fine... but the lower octave only outputs one note when the "octave" number is set to five, otherwise it plays the note at the correctly selected octave, AND from octave five, so you get two notes "the same key" being pressed.
PS Im using mspmax 5 demo version, is this a demo limitation perhaps?
I can't reproduce the problem here, and there doesn't seem to be anything in the patch that would play two notes with one key press. If I had to guess, I would say that maybe you had two "copies" of the patch open at the same time (i.e., the patch was open, and you opened it again). At any rate, the problem couldn't be caused by floats being truncated, as there aren't any floats in the patch. And it shouldn't make any difference that it's the demo.
I, too, only get one note sounding--no matter the octave.
Testing again this morning... i myself was unable to find anything wrong with the file... it would appear that a restart of either the program or the computer solved the problem. HOWEVER... the file is exactly as it was, and no other files were open in max. So there must have been some sort of bug stuck in the program, something which i have suspected happening before, and which i find utterly disheartening
Sometimes these little flukes just kind of happen with Max, even when there's not a problem with the patch itself, and you can't let it get to you. It often happens when a patch is under construction and certain objects aren't yet initialized correctly, or for various other reasons. If it doesn't happen repeatedly, then just don't worry about it. Closing and reopening all patches or restarting Max is a good idea if you suspect that it is a fluke.
I don't want to sound like I don't believe you, but it's extremely common for people to accidentally open a patch when it's already open. Usually they have minimized the patch and forgotten that it is open. The easiest way to prevent this is to get in the habit of never, ever minimizing your patches. Anytime you are using key, keyup, notein, etc. and your patches start outputting twice as much data as they should, this is a possible culprit.
Dude,Quote:So there must have been some sort of bug stuck in the program, something which i have suspected happening before, and which i find utterly disheartening
Sorry to burst your bubble but the objects you are using have been used for over a decade by people with far more knowledge, experience and expertise without these problems you describe.
I am sorry but your problem was 'operator error' and I really think you should at least learn 'something' about the program before you start making claims about problems and bugs. Your other comments lead me to believe you know very little about programming.
Sorry if this seems harsh but that is reality, please continue to experiment with Max - it is quite stable; but start by doing all the included tutorials and those on the net first, and get a working knowledge of the program before asking anymore stupid questions or making unsubstantiated claims.
Sorry mate,
Cheers
Macciza
I know quite a lot about programming... i've been using various versions of BASIC for years, made some cool programs that make nice patterns and also been making music for years. It did look like this program could be the perfect way to mix both things but i am now unsure. If things can go wrong for no reason! And i can assure you, i'm not so retarded i dont know if a patch is open!
Does anyone know of any good tutorials out there on the internet. My defenition of tutorial is something that makes you take part in the process of learning, not something that just tells you what the objects do. Which isn't a good way to sink things in. Doing is the best way of learning!
My path of learning in Max was to go through the tutorials, but then try to extrapolate on them.
I know that most people hate reading manuals or going through the "stock lessons", but I really found that the explanations in text form within the tutors were interesting and always led me into exploration.
Not all tutors will do that.
Personally I love the way the documentation works. Between trying to make new patches based on old, finding time to organize all my files in order to make my library usable, and getting excited about new ideas for patches in order to make new work I am quite happy w/ Max as a tool for building.
This forum is (can be) quite a great place for learning how to troubleshoot your problems in Max and I think that the people in this post are simply asking that there be a sort of "exhaustion measure" executed in your process before posting a question.
Hope this helps,
jml
I wasn't suggesting that things go wrong for no reason; I was just saying that if there doesn't seem to be anything wrong with your patch and the problem doesn't reappear, then it's not necessarily worthwhile to try to discover the source of the problem. Just move on. This applies to just about any program, not just Max.
As for the tutorials, click [Help] [Max Tutorials]. I am sure that you have not looked at these tutorials yet, based on your description of them.
HiQuote:I know quite a lot about programming... i've been using various versions of BASIC for years
BASIC ?? OMG??
Maybe you should try SuperCollider instead if you want to code ;-}
Your questions and statements demonstrate a real lack of basic programming knowledge or skills. Anyone with a 'lot of programming experience' should be able to run Max quite easily by merely jumping in and using it, all the necessary info is in the program itself, no need to wade through API's, Headers, reams of code etc
Quote:Does anyone know of any good tutorials out there on the internet
Well apart from all the tutorials in Max itself - see Tutorials in FileBrowser, and the 60 or more tutorial accessible from the 'Articles / Tutorials' in the menu at the top of this page; an internet search on 'Max Msp Tutorials' will give you hundreds of tutorials. It seems to me you know as little about the internet as you do about programming and Max. You can also search this forum (over a decade of Q&A's), something you should really do before you ask your next stupid question, or make a silly bug claim.
Again sorry if this seems harsh, but your actions leave little option.
Cheers
Macciza
Macciza wrote on Tue, 21 July 2009 05:36
Again sorry if this seems harsh, but your actions leave little option.
actually there are a lot of other options.
-110
Quote:actually there are a lot of other options.
Yeah, that was not the best way of expressing what I meant . . .
It just would have taken too much to elaborate on it . .
Apologies to any concerned parties . .
Cheers
Macciza
Crinkle wrote on Sun, 19 July 2009 07:12Talk about following the m25 to get into london! Why not just make the + - / * objects handle BOTH?
This has been answered by others, but there's another answer to this and it is that Max is 20 years old. This means that the odds that there are still bugs at such an elementary levels are exceedingly low. There are bugs in Max (I just had a mysterious crash), just almost certainly not in places like [+].
That Max is 20 years old also means that despite the curvy vectorized interface, we're all stuck with design decisions that made sense (or not) 20 years ago. 20 years ago, it sort of kind of made sense to have a high-level language like Max be strictly typed. However, nowadays the only reason that Max needs to distinguish between int and float is backward-compatibility with the thousands upon thousands of patches Maxers have made over the last 20 years. If Max were to be redesigned now, all numbers would probably be treated as 32 bit floats. As a matter of fact, this is how Pure Data works.
Now, when working with large data sets, like you do in Jitter, strict typing makes a lot more sense.
Int/float is the biggest quirk left over from the old days (the backwards gate object is another) but it's certainly no where near as bad as BASIC, which is just a single massive, monolithic quirk from the bad old days.
jmpelletier wrote on Wed, 22 July 2009 12:13Crinkle wrote on Sun, 19 July 2009 07:12Talk about following the m25 to get into london! Why not just make the + - / * objects handle BOTH?
This has been answered by others, but there's another answer to this and it is that Max is 20 years old. This means that the odds that there are still bugs at such an elementary levels are exceedingly low. There are bugs in Max (I just had a mysterious crash),
just yesterday was it when for no reason a newly created
[* 2.] object returned "0.5" for an input of "1." until
the patcher was reopened.
and i think we all know the the mysterium of the [select]
object which keeps outputing bangs after it was renamed
to a [route] object.
or those patches where one of two numberboxes suddenly
starts displaying numbers without float display correction
but the other one not.
i think if i would use basic or C++ i would really miss those
things, it gives maxmsp a form of personality no other language
will ever have.
-110
Roman Thilenius wrote on Wed, 22 July 2009 15:59just yesterday was it when for no reason a newly created
[* 2.] object returned "0.5" for an input of "1." until
the patcher was reopened.
and i think we all know the the mysterium of the [select]
object which keeps outputing bangs after it was renamed
to a [route] object.
or those patches where one of two numberboxes suddenly
starts displaying numbers without float display correction
but the other one not.
If you search long enough you'll find the reasons for these behaviors.
If you send a [* 2.] object a list, its the same as if you send the second element to the second inlet (I bet on this explanation)...
I always have to replace selects with route, this is entirely expected behavior, much appreciated...
And to Crinkle:
I wait at least 3 days before claiming that a standard object, which had been used a billion times, has a bug. My experience in Max is almost 20 years. You should wait at least 30 days, and for each year of experience you can lower it by one day...
I mean experience in Max, not in Basic (which I think stopped being used frequently after nobody could get an Atari anymore...)
The advantage of waiting is, to really understand the original aim of an object. In 99% of all cases, the problem is self explanatory and doesn't need to be mentioned at all, but I learn from it. The remaining 1% is welcome here on the list...
Stefan
Is this a troll thread? Of course floats and ints are separated. I doubt many of us can do without, it would be highly confusing at least. It's best to keep everything explicit, like nearly all programming languages do. Who doesn't use [/] and [%] for counting? Yes, BASIC mixed up floats and ints and JS mixes up everything, that's why everyone dislikes them. You'll just have to start using Max, over time many things will start to make sense. GL.
stefantiedje wrote on Thu, 23 July 2009 11:08
If you send a [* 2.] object a list, its the same as if you send the second element to the second inlet
but "1." is not a list at all.
-110
Bas van der Graaff wrote on Thu, 23 July 2009 21:53Of course floats and ints are separated. I doubt many of us can do without, it would be highly confusing at least. It's best to keep everything explicit, like nearly all programming languages do. Who doesn't use [/] and [%] for counting?
On one hand: Ada, ALGOL, C, C++, C#, Objective C, D, Delphi, Pascal, Java.
On the other: Haskell, Javascript, Lua, Perl, PHP, Python, Ruby, Smalltalk, Visual Basic, Supercollider, Pure Data.
Really, which of the two groups does Max seem to belong to? From where I stand, it seems to me that there are more people who dislike languages in the explicitly-typed list than the implicitly-typed one.
Furthermore, if you take a look at the examples in the SDK, you'll find that Max objects already have to do type checking. The overhead mentioned earlier by Roman already exists. That most objects' return type is based on their argument at init time is entirely a design decision. This is definitely a quirk, and although it's a well-documented feature, we shouldn't assume it's necessarily the best way to do things simply because we got used to this quirk. If you send [+] two floats, why shouldn't it output a float?
Like I wrote, the only good reason is backwards compatibility with the scores of patches that have things like [float] -> [/ 10]. The same behaviour could be obtained by using [float] -> [/ 10] -> [int]. That's one more object, but the intent is actually clearer.
of course when it comes only to the look and feel (i.e. not
the "optimisation" issues) maxmsp (and some other languages)
always allow you to roll your own.
you can make a [my+] abstraction with a [+ 0.] inside at any
time and use that for all your numbers, forgetting about the
difference of float vs int of the [+] object.
i have an abstraction called [110.op] which can do + - * /
depending on its middle inlet.
you could also make our own abstraction which understands
"(4+7)/11" and outputs the result as picture, or write a
custom C++ external for maxmsp which is doing that.
the only limit is that you should not create a custom [+]
replacement which is called [+], that will cause you some
trouble with the community as well as with your patches.
-110
.