leaozinho

I'm trying to create a granular sample playback patch using gen~ and poly~. The basics are there, but I'm having a problem when changing settings in my patch. Changing 'LENGTH' or 'DENSITY' always results in a sudden burst of noise before settling down into the expected behavior. I thought that using the [latch] object in [gen~] would get rid of such behavior by only letting these parameter changes through based on the trigger input, but they don't seem to be helping with that. This is one of my first forays into DSP so I'm guessing I'm just missing something and am hoping someone might be able to check out my patch and point me in the right direction. Thank you for all the help :-). I included an audio file in the folder but you can use your own by just dragging into the buffer~ object named "audio".

sample_granulator.zip

I'm trying to create a granular sample playback patch using gen~ and poly~.  The basics are there, but I'm having a problem when changing settings in my patch.  Changing 'LENGTH' or 'DENSITY' always results in a sudden burst of noise before settling down into the expected behavior.  I thought that using the [latch] object in [gen~] would get rid of such behavior by only letting these parameter changes through based on the trigger input, but they don't seem to be helping with that.  This is one of my first forays into DSP so I'm guessing I'm just missing something and am hoping someone might be able to check out my patch and point me in the right direction.  Thank you for all the help :-).  I included an audio file in the folder but you can use your own by just dragging into the buffer~ object named "audio".

I'm trying to create a granular sample playback patch using gen~ and poly~.  The basics are there, but I'm having a problem when changing se

loud-bursts-when-changing-settings-in-my-granular-patch

If anyone cares, I figured this out.  The problem had to do with the fact that I was handling the triggering of individual voices at different times with a [delay] object inside of my gen~ patch.  I think on a high level this was a poor design approach anyway, but more specifically it was causing the above mentioned 'bursts' of audio.  I'm now handling this logic outside of the gen~ patch and it's working much better.

Loud bursts when changing settings in my granular patch

lorenzo.bianchi

i can't find a way to make the pattrstorage sees the pattr objects of another patches. (not a subpatch, but a totally different patch)

i've been trying also adding another pattrstorage, but it seems impossible.

is it true ? no way to make visible to pattrstorage the entire quantity of pattr used by Max in different patches?

hi all
i can't find a way to make the pattrstorage sees the pattr objects of another patches. (not a subpatch, but a totally different patch)
i've been trying also adding another pattrstorage, but it seems impossible.
is it true ? no way to make visible to pattrstorage the entire quantity of pattr used by Max in different patches?

hi all
i can't find a way to make the pattrstorage sees the pattr objects of another patches. (not a subpatch, but a totally different patch

pattrstorages-and-pattr-in-a-different-patches

yes, but in my understanding it works just in a patcher and its sub patchers. it can't reach pattr in another patcher.
am i wrong ? 

ohh sorry I thought you meant it was a subpatch. Well it could still work becaus ethere are somethings which are global in max, although I never tried it, I think a buffer is shared between all max instances, so if so, you could put a value in a buffer and see if it appears in a buffer in the other patcher.  

thanks!! i think Pattrmarlker will somehow works, i'll check it out.

pattrstorages and pattr in a different patches

Arnau Brichs

Probably someone has asked this already, but is there no way of assigning a shortcut to the Audio status and the other tabs in the options menu? (or assigning shortcuts to the menu in general)

Hello,
Probably someone has asked this already, but is there no way of assigning a shortcut to the Audio status and the other tabs in the options menu? (or assigning shortcuts to the menu in general)
Thanks.,
Arnau

Hello,
Probably someone has asked this already, but is there no way of assigning a shortcut to the Audio status and the other tabs in the op

audio-status-shortcut

Not sure about Windows, but on MacOS you can do this in System Prefs > Keyboard > Shortcuts > App Shortcuts.

Audio Status Shortcut

esnho

I don't know where to post this, maybe, feature request.

Is it possible to make the codebox font size modificable?

I'm on windows and I can't zoom the screen so, I'm loosing my eyes :)

codebox-font-size

hey there... i know this is from a looooooong time ago!  ;) 
i'm just getting into gen~, and have the same question... the codebox font size is really too small on a modern 4K monitor!
please let me know if you ever found a solution... cheers!
.pltk.


Select the codebox, open the inspector, and change its font size. 

i'm sorry, i was inaccurate... i'm speaking about the code side panel, rather than a codebox inside the gen patching space.

yes, i can change the font size in a codebox as you describe -- thankyou for that! but is there any way for the code side panel?

Codebox font size

Alexandre

Since 5 years that I made these little efficiency tests (attached here), there have been many discussion on the forum about javascript vs java vs C, and the feeling that often comes out - false, i think - is illustrated by this Emmanuel Jourdan sentence :

"JavaScript is slower than Java indeed, and Java is slower than C. That's in term of CPU/memory usage. In term of development time, it's about the inverse..." ( 

https://cycling74.com/forums/max-vs-java-vs-javascript-speed

Javascript execution is not only 3, 10 or 20 times slower than java, it IS between 200 times and 400 times slower than Java, in my test: In 4 millisec., my little test calculation loop is computed only 200 times in js, while 40000 times in java, on my MBP. (As probably every 'interpreted' code, max patchers execution is also around the same speed, 200 times slower than Java.) Now Java is about 1,5 slower than the C test (non-block-calculation), which, in most situations, is almost nothing. Ok for java, there is this JVM bridge little bottleneck every time that you cross an inlet/outlet, which is around 1 microsecond. Ok that's not always negligible, but well, when you make an mxj or javascript object, ...you are making your loops inside it, so you're not supposed to [uzi] very fast over it... By crossing this JVM bridge the less often possible, for example by joining numbers into list before sending thru an inlet/outlet (which mean crossing this bridge only once) i'm then really peaceful with this bridge, since 5 years, and there's no point for me to go to C.

To me, if you use it to make some max objects the same way you would using Javascript, Java is as easy to learn. (It will only be more complex to learn if you want to go further thru "inheritance" concepts and stuff... to things you can't do with javascript.)

Now, using the great Eclipse developing environment for Java - far better than the Java editor inside max - the development time should be - at least - AS FAST AS Javascript. The assisted editing make it even more convenient than javascript. Just the syntax is a little bit different from Javascript but it's not few more semicolons that are gonna slow you down.

About C, beside its slower development time, a real pain is that, from what i understood, you have to restart max every time you modify your object. ( 

https://cycling74.com/forums/how-to-load-rebuilt-external-without-reopening-max

 ) Not the case in java and javascript where you can refresh the max object.

There's a great 'Step by Step Instructions tutorial' from Adam Murray, to use Eclipse with max: 

http://compusition.com/web/articles/maxmsp-eclipse

...in just a half an hour process, you're into java... So why Javascript ?

I understand that the Javascript field is non-timing-sensitive stuff*, like UI related code, but in the beginning era of multi-touch - cf. 

http://www.youtube.com/watch?v=tfvEV1zcAjQ

 - then even UI related routines are going to be called more and more often, then even for that, Javascript could bring signifiant slow down, compared to java, in the future.

5 years ago, I remember a discussion with jkc saying he liked javascript, but 5 year after i'm still asking myself why.

I don't get why so much maxers are using Javascript and C, while fewer are using Java. ( 2 times more messages on the Javascript forum than on the Java forum )

P.S : But there is again worst than javascript: look at the [coll] object efficiency in the 'test-on-arrays'...

* in the WritingMaxExternalsInJava.pdf doc : "For timing sensitive events the js and jsui objects should not be used"

Since 5 years that I made these little efficiency tests (attached here), there have been many discussion on the forum about javascript vs java vs C, and the feeling that often comes out - false, i think - is illustrated by this Emmanuel Jourdan sentence : 

"JavaScript is slower than Java indeed, and Java is slower than C. That's in term of CPU/memory usage. In term of development time, it's about the inverse..." ( https://cycling74.com/forums/max-vs-java-vs-javascript-speed )

Javascript execution is not only 3, 10 or 20 times slower than java, it IS between 200 times and 400 times slower than Java, in my test: In 4 millisec., my little test calculation loop is computed only 200 times in js, while 40000 times in java, on my MBP.  (As probably every 'interpreted' code, max patchers execution is also around the same speed, 200 times slower than Java.) Now Java is about 1,5 slower than the C test (non-block-calculation), which, in most situations, is almost nothing. Ok for java, there is this JVM bridge little bottleneck every time that you cross an inlet/outlet, which is around 1 microsecond. Ok that's not always negligible, but well, when you make an mxj or javascript object, ...you are making your loops inside it, so you're not supposed to [uzi] very fast over it...  By crossing this JVM bridge the less often possible, for example by joining numbers into list before sending thru an inlet/outlet (which mean crossing this bridge only once) i'm then really peaceful with this bridge, since 5 years, and there's no point for me to go to C.

To me, if you use it to make some max objects the same way you would using Javascript, Java is as easy to learn. (It will only be more complex to learn if you want to go further thru "inheritance" concepts and stuff... to things you can't do with javascript.)
Now, using the great Eclipse developing environment for Java - far better than the Java editor inside max -  the development time should be - at least - AS FAST AS Javascript. The assisted editing make it even more convenient than javascript. Just the syntax is a little bit different from Javascript but it's not few more semicolons that are gonna slow you down.
About C, beside its slower development time, a real pain is that, from what i understood, you have to restart max every time you modify your object. ( https://cycling74.com/forums/how-to-load-rebuilt-external-without-reopening-max ) Not the case in java and javascript where you can refresh the max object.

There's a great 'Step by Step Instructions tutorial'  from Adam Murray, to use Eclipse with max: http://compusition.com/web/articles/maxmsp-eclipse 

I understand that the Javascript field is non-timing-sensitive stuff*, like UI related code, but in the beginning era of multi-touch - cf. http://www.youtube.com/watch?v=tfvEV1zcAjQ - then even UI related routines are going to be called more and more often, then even for that, Javascript could bring signifiant slow down, compared to java, in the future.

I don't get why so much maxers are using Javascript and C, while fewer are using Java. ( 2 times more messages on the Javascript forum than on the Java forum )
Perhaps it's just a lack of publicity ?
i'm making it... :-)

* in the WritingMaxExternalsInJava.pdf doc : "For timing sensitive events the js and jsui objects should not be used"


java-200-times-faster-almost-as-easy-to-use-so-why-javascript

"I don't get why so much maxers are using Javascript and C"

C is still faster. '1.5 times' is not an absolute measure for everything... and it can make a big difference very fast in the development of larger apps.

as for javascript, i'm not an expert and i do shy away from it(in Max) because i like C better, but it's the same argument as trying to say that you are happy to use Java even though you know C is faster. there's different situations suited for different things. there are situations where javascript does not take up much CPU at all. in those situations, the ease of quick scripting is applicable as an adequate substitute for lower-level programming.

also, you develop C externals outside of Max, true, therefore you have to restart, but to me it's a negligible amount of time, when people talk of 'slower development time' for C, that's completely subjective: usually more true for those who are just plain slow at using their IDE and at programming in C.

you make a good argument about javascript and java but your PPC compiling of C externals in your test while most are using intel these days and your arguments against C(while C is the cornerstone of how everything in Max was originally created), takes away from your argument by distracting it from the java/javascript relation alone and also may lead one to wonder why you've avoided the subject of C++ altogether.

It is good to hear your passion for Java, though!


I guess it really depends what you are trying to achieve.

I have and do use all three. I don't think there is a good argument for only using one.

If you (in many cases meaning me) are really serious about efficiency then C is probably the best way to go. 1.5x might be significant if you are writing audio code that is already expensive.

Java has cross-platorm on it's side (that's the big plus for me).The garbage collection is a lot easier, but I'm not usually worried about cross-platform - I know the C API very well, and I can deal with garbage collection, so normally the speed wins out - when compatibility is a concern then java is normally my choice.

Javascript is slow, but sometimes it's just the easiest. I use js a lot when I have an esoteric thing that I can't quite do in max, but the js API allows and I'm not going to want to reuse it a lot and speed is not a concern. Learning time for a language is not the only speed concern. I can write a quick routine in js in under 2 minutes and have it running. I doubt I could be as fast in java or C, even working from a template. THat is what development time means - not how long it takes for you to learn how to do it.

The last thing which you fail to consider is the API available in each. One of the quirks of developing for max is that the APIs are all different. That means that sometimes it's really straightforward to do something in one, and not in another. Let's say I want to read a textfile without character limitations in. I did it in js in less than 20 lines. I don't think I've ever written an external in java or C that was anywhere near that compact.

Great that you feel Java suits you, but each to his own. I can't help but think that when suitable, javascript is normally fastest to code, and often that is what counts.

Noob4Life, you are right about C efficiency can be better than '1.5 times' specially for block calculation (audio externals, jitter). Sorry I don't have the intel version compiled for the C test because it was made for me by a guy at ircam five years ago. I doubt the '1.5 times' would change a lot anyway.

> AlexHarker :  "I can write a quick routine in js in under 2 minutes
> and have it running. I doubt I could be as fast in java, even working from a template.

from a template, that's 3 minutes for Java...

>  One of the quirks of developing for max is that the APIs are all different.

Considering the too limited time that C74 team have to develop the full max API for each language, i feel that pattr and UI support for Java, instead of Javascript, might have been the best choice, for a real-time-sound-and-image software where efficiency and timing is an eternal question.


By the way. I'm not sure I believe your figures totally.

Try the below. this would seem to indicate that js slightly less than twice as slow on my computer (around 2000 milliseconds plays 3300 ish). Bang the little button...

Can you confirm your results and comment. I haven't had time to check your patch in detail but this is a simple tried and tested way of measuring speeds. I'm on intel so I didn't do the c compile...

Assuming my figures are right (which they may not be) that would somewhat change everything no?

My bad - I see now that you loop fois * 10 in the java code and fois / 10 in the js. Confusing but fair enough - that would account for the factor of 100.....


Considering the too limited time that C74 team have to develop the full max API for each language, i feel that pattr and UI support for Java, instead of Javascript, might have been the best choice, for a real-time-sound-and-image software where efficiency and timing is an eternal question.

++ to mxj supporting pattr integration!  Hoping it is coming soon.


any use of javascript and java inside maxmsp should be illegal.


Yes AlexHarker, It was necessary to put this /10 for js and *10 for java and c, in order to avoid: 1- minutes to wait for the js to compute, 2- eventual bad precision over java an C if the test is too short. Then the compute time is corrected by multipling by this factor. (third [chrono] inlet in my patch). Sorry if my test then looks a bit complex.

>>  ++ to mxj supporting pattr integration! Hoping it is coming soon.

Do you really think that could come soon?  This would be nice. But looking at theses old topics ( https://cycling74.com/forums/pattr-support-in-max-5 and https://cycling74.com/forums/notifyclients-in-java ), it doesn't look like coming soon.

>> any use of javascript and java inside maxmsp should be illegal.
What should be illegal is the use of patch cords for sequential and algorithmic stuff. Looking at other people algorithmic patches just give me headaches. What i made in Java would have cost 10 time more developing time using patch cords. Keep max for its best: Real time events, audio, UI.


Yes - I guessed as much once I'd figured that out.

I get about 160 times faster here on a dual 3.0GHz MBP.

FWIW - the javascript calculations as far as I know are double precision - the java ones are not. I wouldn't want to speculate too much on what difference it would make, but I think you'd see it in the figures.

Obviously, single precision in javascript is not an option, but it would be better to compare like with like as far as possible...

I can't help but feel however, that you are looking at large data, large loops within loops situations that may not be typical uses of javascript. I'm not going to disagree that js is bad for this, but in small applications I think you might find that worrying about cpu usage is a waste of energy. After all - if you have a process that takes 1% of your processor (for example) in a scenario where you are running at around 67% - then when you speed that up by 200 times you simply won't see it clearly in the results - so it's not good economy. If it takes up 40% of your processor however....


"Any use of javascript and java inside maxmsp should be illegal. "

I've broken the law.  rehabilitate me.  someone! I've been trying to get started with C/Max for 5 years now.  never got off the ground.    Why?  The thing I've had problems with in every language isn't the language part but the way it's set up on in the OS.  There are never any details about it in any tutorial.  There's always a line "find foo.baz.clib on your drive" and it's never there.  I've spent four years programming mxj externals and I have no frick'n clue what ANT is, how to write scripts for it, or where "java" is on my drive. I open eclipse, include max.jar and I'm done.

Maybe that makes me not a "real" programmer. I couldn't care less.    

I'll try again soon when I get around to installing snow leopard but  setting up max and C has taken weeks of my life and I've never gotten it right.

That comes off ranty..  but it's more a rant of desperation :-)


I have used JS to develop two or three projects. As most of them were non -realtime I didn't care about efficiency. I chose JS essentially because I wanted to use the drawing capabilities of the JSUI object and because as a non-programmer (I mean no experience in any formal language outside Max, SuperCollider and GW-Basic). I also wanted the shortest possible learning curve.

I had one project to create rhythmic patterns using JS. Reading the resulting data in real-time with JS produced tons of clicks while reading them from colls worked correcly (althought transition between Max4 and Max5 showed some reductions in performance for very fast MIDI rhythms).

I have been thinking about learning C several times but I always postpone it.

> the javascript calculations as far as I know are double precision

I even didn't know. in attachment is the version with double in java, which is 2 time slower, in fact. (good to know)

I have a question: Is there anyone having a example patch that cannot be done using only floats precision ?
(I've never used double, and whenever i use the Java.Math methods i immediately convert in float.)


> but in small applications I think you might find that worrying about cpu usage is a waste of energy.

The problem with small applications, is that they often get bigger, or that one day you need to load a bunch of them for a live or something, and then nothing is working as before and you don't know why. 

If we were talking about a factor of 1,5 or 2, then ok, worrying about cpu usage for that may be a waste of time for a small application. But we are talking about a factor which is between 100 and 400 (yes, 400, see my 'Efficiency-test-on-arrays.pat': the loop is computed only 1000 times in js, while 400000 times in java, on my MBP.)
Compared with java, to me, javascript is mostly a waste of energy for the computer.

...Ecologists would even make javascript illegal, what about your computer carbon footprint?
:-D


If MaxforLive already included LiveAPI integration for Java, I'd be on the bandwagon...for now I'll code it in js and convert it when it needs done.

(actually, I guess it makes little difference since the LiveAPI is low-priority anyway)...

Still...the link to the tutorial above is helpfull...I've already installed Eclipse and started reading about Java.  There are several things I wrote in js before I had to convert them into pureMax because js was too slow.  I'd much rather have them in a script language....editing algorithmic stuff in Max is like trying to popular music trends....


Double precision is a real necessity in certain scenarios - for instance:

phasor accumulation (for audio rate buffer playback for example)
calculating certain filter coefficients accurately

My personal experience of double precision critical situations is more in the domain of audio rate programming admittedly, but that is just me.
You seem to be suggesting that doubles are unnecessary. I'm trying to suggest that everyone's needs are different, and if java is twice as slow with doubles (that is inline with what I expected) - then on my computer you are looking at closer to 75 - 80 times slower for js doing the same thing - which is a substantially different figure to 200. Sometimes the speed gains offered by C *really* matter to me, whereas to you it isn't worth it.

As for arrays - sure - I didn't say it was fast, or good for that. However, in the event that you do very little in a function call and you make the function call lets say every 10ms (which is really quite often compared to a message-based musical timing) - the CPU you might be talking about is really not worth worrying about.

Believe me II have spent many hours optimising cpu and memory usage - to the point of ridiculous obsession. I understand the drive, but rule 1 of optimisation is don't optimise. It has many disadvantages. Rule 2 is optimise what matters first. Let's take Chris Muir's simple FM patch from a recent thread. Turns out that mtof~ accounts for over 50% of the cpu that that patch consumes. I can spend all the time I want optimising other parts, but some of them are so negligible that I could put in hours and hours and never see any real gain. I replaced mtof~ with a more efficient alternative and the patch ran almost twice as fast (55% with 32 voices down to 28%)...

Often I am using js for one off calculations / loading processes / things that happen maybe less than once a minute. Unless those operations are noticeable intensive then optimisation is not a concern.


Alex wrote, "Often I am using js for one off calculations / loading processes / things that happen maybe less than once a minute. Unless those operations are noticeable intensive then optimisation is not a concern."

ya, this is what i was trying to say... for such contexts, a quick scripting language(like JS/Python/etc.) seems better than any small efficiency gains you get from a lower-level language.


Oh please, the days of low-level languages for general purpose programming is over (should be anyway).

Using C as an application language was never a good idea and still isn't. It was designed for system programming, and that is were low-level concepts such as direct access to memory should stay. The programming platforms of the future are probably going to be virtual machines supporting dynamic linking, JIT-compilation (which already beat AOT-compilers in speed) and garbage collection on the fly.

One reason to use JavaScript over Java is that it is a functional and more expressive language. Another is that is has direct access to the Max scheduler and object system, which Java has not. If speed is an issue, you can switch to Rhino and compile it to JVM bytecode, which will execute at java speed (this would of course restrict you to the Java API).


Hans Hoglund wrote: "Using C as an application language was never a good idea and still isn't."
I think everytime people bring C into the debate between Java and Javascript, it's going to distract from credibility on other points(JMax is dead, btw).
I agree with most of what you say, but this holds no water whatsoever considering we are all here because of an application called "Max" which was(and to a great extent still is) written in C.


@Noob4Life I have no problem using and relying on stable software. What concerns me is that the performance arguments is used to hold back the emancipation of new and better languages. I think it should be the other way around, we should look out for more expressive ways to program and then consider implementation.

Of course Max was designed to connect C programs, that was the the accepted way to do real-time back then. Now we have other options, there are hundreds of languages with safe memory, lambdas and dynamic dispatch that are fast enough for real-time, many of which can be integrated in Max.


"I think it should be the other way around, we should look out for more expressive ways to program and then consider implementation."

well put! after all, all 'languages' serve the primary purpose of communicating and disseminating any form of information(efficiency concerns are not always paramount to communication).
if we talk of the future, i believe all apps and data will be web-based eventually, and personal comps will only be a terminal to that network, this will actually be more affordable and will provide better access to information for even 3rd world countries... sounds dangerous to comprehend at first, but since i don't think google/verizon/microsoft will ever succeed in completely limiting/commodifying our access and presence on the web, it's very possible... therefore, i agree with all your statements of what options we have and will have.


I have never really understood why people want to do time critical
operations with Java. As a software developer designing a real-time
system, the last thing I want to build into it are unknowns like
garbage collection and byte interpreted instructions. That just
adds unknown inefficiencies that keeps you from squeezing all the
power you can out of your system.

Max is an open architecture that allows you to insert your own
objects in that audio and data signal path. It is supposed to
be as efficient as possible. Implementing your algorithm in C
is probably the best compromise between readability and effecienncy.

But for doing UI stuff I think javascript is decent. Although I
think python is a much better language. I hope that one day, Cycling74
will add native support for it. I would love to have access to SciPy
in Max!


"python is a much better language. I hope that one day, Cycling74
will add native support"
+1 4 Python!


@Anthony Your arguments are just not valid. The JVM of 1990s were slow, modern implementations are not. GC and JIT are not "dumb overheads" but higly intricate compilation techniques that may actually yield better performance than a C compiler. That JVM's are slow is just a plain old myth.

What Java has is a slow startup time (about 500 ms on my machine, and this happens once when you load your first Java class). This is not because of JIT, but because Java links everything dynamically. The benefits of this are so huge that I have no problems with a split-second startup delay.

Furthermore I would argue that in a real-time application stability is more important than raw performance. In Java code you will never have a memory error except if you mess up concurrency. Use Clojure and you will not even have that.


Also, why should we need to compromise readability to have efficiency? Why not use a language that has both? (Not that Java does).


>> Why not use a language that has both?
Good question.

>> But for doing UI stuff I think javascript is decent.

Try ej.fonction.js from the ejies, put lot's of segments and manipulate the visualizations, then javascript is not decent anymore...

Comparing a javascript code with the same thing done in java, to me, in general, that's nearly the same in term of readability. The situations were javascript really looks more "expressive", are not coming so often to me, looking at codes.
(plus, the really nice way that Eclipse manage color for instruction types and highlight other variables when you type on one, makes java even more readable, in my personal experience.)


"I would argue that in a real-time application stability is more important than raw performance. In Java code you will never have a memory error except if you mess up concurrency. Use Clojure and you will not even have that."

You obviously know your stuff, and I respect your opinion, but this argument at least is void if the programmer deals with memory allocation and access correctly. Also, as always YMMV with regards to the importance of raw performance. As we are dealing with a real time audio language here, and portable computer power is not infinite, I think it is clearly arguable that in some scenarios available processing power limits what is desirable, and therefore raw performance is highly relevant. In time critical situations 20% (as quoted in the linked article) slower may simply be unacceptable.

In reality I simply don't believe that 20% is a typical figure for what is being discussed here (max external in java vs one in C). I'd be happy to be proved wrong, but I'll be sticking to C for efficient audio processing until then.

Don't get me wrong, I'm not arguing against the use of java, I'm just think that any choice of language is based on a combination of factors, and there are clearly arguments in all directions - using the most appropriate language in the circumstances seems would be my approach, and for me that could result in using C, java or javascript.


Me, I'm not arguing against the use of C, but let's feed these interesting debates :
About C vs java, in the C74 WritingMaxExternalsInJava.pdf doc, page 43, from Topher La Fata :

"A properly written
Java signal processing external is typically about 1.5-2.5X slower than the equivalent
external written in C. A lot of this depends on what sort of processing your external is
doing. In most cases the more computationally expensive your external, the closer that
the Java and C versions will be in performance. This is because the biggest overhead
introduced by doing your signal processing in Java is in the context switching that occurs
when the mxj~ bridge calls from C into your Java signal processing routine. The cost of
this context switch is amortized across the amount of time you spend actually
accomplishing your task, so the more expensive your task, the less relatively expensive is
the cost of the context switch."


"Me, I'm not arguing against the use of C," but then you go on to do just that. At least be truthful rather than hypocritical. (Also, the quote starts with the wording "typically" and "depends on what sort of processing your external is
doing", so it's not an empirical statement whatsoever.)

I think what everyone is doing here is only proving that developers are extremely high-maintenance people ;) The discussion is whittling into something uninteresting and convincing me to stay away from Java(since devs in that environ seem more desperate to talk sh!t about all others more than anyone else i've seen). What you've convinced me of, is that even though you don't think it's significant, C is still significantly faster than Java(because 1.5-2.5xfaster can make a very big cumulative difference to me).


With all due respect Hans, I definitely see the merit of your
argument. Java VM technology has certainly advanced in the last
10 years. 

But I feel a lot of these benchmarks people quote are perfect scenarios
that don't really reflect the real time performance environemnt
of an integrated system (memory latency, kernel i/o, graphics/audio
interfaces). You can argue all you want about how some JVM does an FFT faster than C, but put it in a real world environment and I think
you'll see different results. 

Arguable the most complex real-time audio/graphics system out there
are console game systems like the PS3 and Xbox. Why hasn't Sony or
nVidia, chosen Java as their development language/environment of choice?
Because it is an inefficient language for that environment.
Having done video game development for 7 years now, I know for a fact
the tremendous work that goes into squeezing every drop of processing
power out of these systems. You are interfaceing with DSPs, GPUS,
pixel/vertex shaders, etc. Implementing things in Java would be a joke,
I mean really.

Why would I not want my Max patch to perform at the same level?


Whatever happened to testability?
in java, in javascript, and MAX MSP?
Why don't we do comparisons to settle this please?
This whole thread confuses me!

http://www.youtube.com/watch?v=9fI_jdOrYPc


> "and MAX MSP?"
From what i remember when looked at it, i think Max-Msp execution speed is more or less the same than javascript execution speed. (or something between 0.5X-2X)

To make it clear: I am NOT arguing anything against C. I just mean that to write externals, Java is almost as great - and really more simple to use in my personal point of view - in most of the situations that i encounter. Sorry, I would add 3 words to this sentence from my first post, which some can find provocative, if i could : "Now Java is about 1,5 slower than the C test (non-block-calculation), which, FOR MY PURPOSE, in most situations, is almost nothing." C is great, Java is great, Max is great, MMF for Ipad is super Great!, and we are all great people!


"I was just screwing around :-)"
no one blames you, either, it's getting hard to take this thread seriously.


Implementing things in Java would be a joke,
I mean really.

I think this is still the old prejudice, but no matter. Performance of JVM for critical tasks has and will countinue to be widely debated. Of course Max is fundamentlly a native environment and integration with any VM can never be entirely smooth. 

I always figured the main reason for JavaScript in Max was there to provide a more lightweight interface to patcher scripting.


Wow, a well timed article considering I've been thinking about this over the past few days. If I could add a little bit of a hypothetical situation though...

It seems that we now have a lot of work being done on JavaScript engines, with the likes of Google's V8, Apple's Nitro and Mozilla's JägerMonkey. If one of these was implemented into Max, would there be enough of a performance gain to put it anywhere near level with Java? As I understand it, these new engines are starting to compile directly to bytecode rather than just interpreting.


@DiGiTaLFX Agreed, there are many promising new implementations. Personally i use Mozilla's Rhino and compile to JVM bytecode which runs like lightning. I am not doing real-time audio in it though ;).


@Hans I've been checking this out....how much Java do you need to know to work in this manner? I am also not doing RT audio, but I need faster processing for arrays and such...I'd like to start working on some flocking/algorithmic stuff and the last time I did this sort of thing in js I ended up having to rewrite the whole routine in pure Max b/c it was just too slow...I'm thinking this might be a nice alternative, without having to spend the extra time on the front end learning a new language.


> " the extra time on the front end learning a new language."

Does this look that much more complicated ?

It definitely is Alexandre. For you it's not because you're used to it. If you look at the same thing in C, you could have the same conclusion, it's not really much more complicated, as long as you have the skill, time… That's the reason why there's the 3 approaches, they are not equivalent in term of performance, nor in term of knowledge required, development time, cross/platform... Just use the language you know, and if that's not fast enough switch to the next one ;-)


@alexandre agreed! Do you have the same code in C? I'd love to see a side by side comparison of all three languages.


The code in C, "calcultest.c", is in the "Efficiency-Tests-Nov2005.zip" attached above, in the first post of this topic, although i think that it could really be shorter (not made by me - i don't use C - but by Diemo from Ircam 5 years ago).

Also, Emmanuel is right that this js/java example above is a bit too simple. There ARE more differences between coding in Javascript and Java that are not shown here. I just posted it to show you that java is not so complicated.
Like I say on my first message, and like AudioMatt meant, i think : To just use java for mxj externals, it's ok if you have a light knowledge* of its structure. (Inheritances,polymorphism,etc... After few years of using java for mxj externals, i'm just starting on theses concept now, but that's because my mxj externals start to have thousands of line of code..)

And i doubt about what Emmanuel say about development time, that Java would be slower to code than Javascript: Can someone organize a big Java/Javascript coding competition and see the result ? :-)  I'm wondering that if javascript is faster to code, that from really short... ...For an execution speed lost of a factor which is between 60 -to AlexHarker POV - and 400.

* But you do need to learn a bit about some java stuff: primitive types, operators, cast, arrays and Java.Math class if need some math. This is 10% of my java learning book.


If it's difficult to imagine what *60 or *400 really mean, have a look at my modified version of Flies.maxhelp attached.

Anything like this in a js object is, from far, impossible.

Nope...that doesn't look that much more complicated....but I'm guessing that everything I would normally do in js isn't going to translate quite as easily.  I've gotten used to the way js types variables, and I know how its integration with Max works.  Besides:  a lot of the stuff I need to do, I've already written scripts in js for the routines.  Being able to convert already written scripts fairly easily with something like Rhino sounds very convenient.

I will learn Java...its merely a matter of when I will have the time.  I'm also trying to tackle Python right now (and I have a more immediate need for it), which is all that much more confounded by the lack of a decent way to test in Live (I'm working on control_surface scripts).  Plus, it goes back to my original post:  since the majority of my work is with the Live API at present, there is no facility for accessing those objects directly with Java, nor any speed increase since the API can only be accessed low-priority.


FWIW, we are looking into having a much faster JS engine for the next major version of Max.  Java, JavaScript, Python, Lua, and C are all great languages, each with their advantages and disadvantages. If we could easily support everything in all languages we would, but we have to balance our development and maintenance priorities.


That's worth quite a bit (but of course a bird in the hand is worth two in the bush)....


a thousand times yes. v8 with commonsjs modules support please :D ?


Probably not V8, since it doesn't support multithreading, and would require a complete rewrite of much of our code. Jaegermonkey is the one we're watching. Lets of great work happening there, and it's coming close to Nitro/V8 performance.

+2 for Python and LUA (whenever dev priority allows)


Nice discussion, very enlightening to hear such interesting opinions. For me java provides the big advantage of  the possibility of reusing code and the access to very interesting libraries, such as those coming from Processing.  I would love to see a more supported class-oriented approach on the SDK.
Besides efficiency it is interesting to think what kind of new technology can be implemented or bridged inside max(i am thinking of openCL or the quartz technologies, for instance).


So now that Max 6 is out, I decided to run these tests again and see what the difference in performance of the JavaScript engine was. I get around 250 iterations in Max 5 and 650 iterations in Max 6. So that's a 2.5 times increase in performance! It's still way off of the ~27000 iterations I get from the Java VM (double) though...

Would be interested to see if someone could port the test to jit.gl.lua object.

mmmmmm :)  That's good news, I'd love to hear some further confirmation of this....I've started doing stuff that needs to be fast in Java, but I still prefer the ease of js, and use it whenever possible.

On the other hand, how much of the stuff that I reserve for Java (for speed) will be possible with ~gen now, I wonder?

Just a quick comment and examples. Hopefully to illustrate some best practices in JS for improved performance. 

These JS files you've provided make heavy use of global variables, and even then ones which haven't been scoped with var, The former are slow, and the latter are even slower (and dangerous since they are values shared between instances). 

This is true for both the older spidermonkey JS implementation, as well as the new JIT compiled Jaegermonkey implementation. And in the new engine it's even more important for optimal JIT performance.

I've taken a brief moment to revise your examples just comparing your JS with some improved JS files.

Also, some of your examples had codepaths which could possibly be eliminated (e.g. a large loop which sets one variable over and over again, so in effect the only one necessary to set is the final loop value, or if those values are never used in the future, they don't need to be set at all). So they might not be accurate tests of read/write performance, but rather a test of deadcode elimination. I didn't have time to investigate whether or not this is the case.

Finally, also when testing you need to execute a function a few times before JS will completely JIT compile, so be sure to execute a few times to get the optimum JIT compiled benchmark.

That said, Java will be faster than JS. No question. I don't know of any of the new JS implementation which are as fast as the JIT compiled  Java VM. Part of this is because of static typing and other language features.

Javascript, however, gains all that nice small talky dynamic typing and binding goodness, and is in many ways more agile than programming in Java, as long as you don't trip yourself up in the many errors that can happen with dynamic binding when not carefully coded.

Cycling '74 Forums

We are happy to announce the release of RNBO 1.3.0, available now for download via the Max Package Manager. With this update, we are...

We are excited to announce the availability of our Eventide package for RNBO as a public beta. We’ve worked closely with Eventide to...

If anyone cares, I figured this out. The problem had to do with the fact that I was handling the triggering of individual voices at...

thanks!! i think Pattrmarlker will somehow works, i'll check it out. best L

Thanks!

i'm sorry, i was inaccurate... i'm speaking about the code side panel, rather than a codebox inside the gen patching space. yes, i can...

Mayb e things have improved, but before 2003 I kept having to recode java just aobut every other year, so I dropped it. Since then it went...

I have the same problem. Any solution ?

You're not Roger Smith from American Dad! by any chance, are you? ha, no, but we hitched a ride here in the same UFO 🥸👽 So glad it put a...

Thanks for the report. We can reproduce and will investigate!

Hey guys, I‘m pretty new to Max and looking for some help building a synth patch.. I‘m looking for a way to smoothly transit between/mix two

@11olsen Yes, building with a new SDK, VS2015 or higher (Which instead relies on the universal C runtime) and new cmake generated project...