grimepoch

First, is there a dev kit for Max5 yet? I cannot seem to find one on the site.

I am >this< close to upgrading to Max5, because I am having some SERIOUS problems with Java/Javascript code I wrote for Max4 that is just NOT working well that the number of files my program uses has surpased 2000+.

My Java code talks with the OS and gets directory listings when the software starts and returns it all to JavaScript. The files are named as such with LOTS of information in their title (key, BPM, etc) and my JSUI uses this to put good amounts of information on the screen.

The problem comes when I am scrolling the list with an external jog wheel OR using the cursor to drag around a slider in a listbox I created. The perfomance REALLY degrades video playback. It drops from 60 frames a second to less than 15.

I went into the JSUI code and did lots of commenting to see that it was the drawing that is totally killing the performance. For now I have stripped down to JUST showing file names, to make the software usable as I have a gig tomorrow night. Needless to say, this is not a valid solution.

In reading the forums, I see that it is recommended to not put a lot of effort into learning QuickDraw or Quartz drawing as Max5 will have support for Cairo like calls from externals. I don't have a problem waiting, I just want to make sure

(1) This is the intention of Max and Cycling74 moving forward. I'd like to learn only what is necessary

(2) If coding my file browser as an external and doing all the graphics there will actually be faster than doing the graphics in JSUI. Or is my code just going to be calling the same routines and be slow?

I am using large multi-dimentional arrays in JS to store filenames and additional data. I have contemplated testing other strategies, however, if ultimately my code will be LOTS faster in C, then I'd rather bit the bullet and move it there and be done with this issue altogether.

First, is there a dev kit for Max5 yet?  I cannot seem to find one on the site.

My Java code talks with the OS and gets directory listings when the software starts and returns it all to JavaScript.  The files are named as such with LOTS of information in their title (key, BPM, etc) and my JSUI uses this to put good amounts of information on the screen.

The problem comes when I am scrolling the list with an external jog wheel OR using the cursor to drag around a slider in a listbox I created.  The perfomance REALLY degrades video playback.  It drops from 60 frames a second to less than 15.

I went into the JSUI code and did lots of commenting to see that it was the drawing that is totally killing the performance.  For now I have stripped down to JUST showing file names, to make the software usable as I have a gig tomorrow night.  Needless to say, this is not a valid solution.

In reading the forums, I see that it is recommended to not put a lot of effort into learning QuickDraw or Quartz drawing as Max5 will have support for Cairo like calls from externals.  I don't have a problem waiting, I just want to make sure 

(1)  This is the intention of Max and Cycling74 moving forward.  I'd like to learn only what is necessary

(2)  If coding my file browser as an external and doing all the graphics there will actually be faster than doing the graphics in JSUI.  Or is my code just going to be calling the same routines and be slow?  

I am using large multi-dimentional arrays in JS to store filenames and additional data.  I have contemplated testing other strategies, however, if ultimately my code will be LOTS faster in C, then I'd rather bit the bullet and move it there and be done with this issue altogether.

max5-external-for-file-selection-suggestions

I also wanted to add that this problem didn't occur earlier with a smaller list of files so something has to be happening with memory access as well. I am thinking that the memory access and handling in C should be a lot faster than JS for these very large file arrays.

I also wanted to add that this problem didn't occur earlier with a smaller list of files so something has to be happening with memory access as well.  I am thinking that the memory access and handling in C should be a lot faster than JS for these very large file arrays.


On Fri, 05 Sep 2008 00:36:04 -0600, Rick Burnett wrote:

> I am using large multi-dimentional arrays in JS to store filenames 

> and additional data. I have contemplated testing other strategies, 

> however, if ultimately my code will be LOTS faster in C, then I'd 

> rather bit the bullet and move it there and be done with this issue 

Well, not for Max 5 yet, but there's iCE:

On Fri, 05 Sep 2008 00:36:04 -0600, Rick Burnett wrote:
> I am using large multi-dimentional arrays in JS to store filenames 
> and additional data.  I have contemplated testing other strategies, 
> however, if ultimately my code will be LOTS faster in C, then I'd 
> rather bit the bullet and move it there and be done with this issue 
> altogether.
>
> Thoughts?

I took a look a the iCE stuff, and the lattice could possibly work in this situation, although, not with all the bells and whistles I have in my JSUI now that are very nice.

Is there any programming examples of writing a graphical external? If I had something to start with, even using the old method for now, I am sure I could hobble together what I need in no time.

Is there any programming examples of writing a graphical external?  If I had something to start with, even using the old method for now, I am sure I could hobble together what I need in no time.

i think the problems you are having with jsui is to do with the drawing more than it is to do with the size of your arrays. The OpenGL software renderer in JSUI seems quite slow. I would make sure you limit the rate that you call draw() as much as possible (if you aren't allready). Also turn of fsaa.

Cycling have mentioned that at some point the JSUI will be able to use the new drawing API in Max5. I assume this will be faster than using the Open GL renderer.

No, it's not the JSUI because I have been using this code for over a year now and it has not been changed at all. The only thing changing through that whole time is the source files we are looking at. The window has always shown 40 items at a time and started at 700 files that I would scroll through. Now I am at 2400 files. Before, I scrolled just as much through the list and never saw this kind of hit.

I even just drew the text and shapes from a static variable essentially and commented out the array calls and it sped up tremendously.

I did actually try doing some limits on draw, but the problem still comes down to the multi-dimensional array accessing as well. It is very strange, because I set the draw up so it would not redraw in a very short period of time when you were scrolling fast, but the access to the arrays still seemed to cause some kind of choke-up on subsequent passes through draw.

Because of this, I'd like to just eliminate JS completely as our source material is just going to keep increasing. Once the new SDK comes out, I am just going to write an external as I am comfortable with Xcode as well and think the compute savings will be 10 fold.

No, it's not the JSUI because I have been using this code for over a year now and it has not been changed at all.  The only thing changing through that whole time is the source files we are looking at.  The window has always shown 40 items at a time and started at 700 files that I would scroll through.  Now I am at 2400 files.  Before, I scrolled just as much through the list and never saw this kind of hit.

I even just drew the text and shapes from a static variable essentially and commented out the array calls and it sped up tremendously.  

I did actually try doing some limits on draw, but the problem still comes down to the multi-dimensional array accessing as well.  It is very strange, because I set the draw up so it would not redraw in a very short period of time when you were scrolling fast, but the access to the arrays still seemed to cause some kind of choke-up on subsequent passes through draw.

Because of this, I'd like to just eliminate JS completely as our source material is just going to keep increasing.  Once the new SDK comes out, I am just going to write an external as I am comfortable with Xcode as well and think the compute savings will be 10 fold.


On Wed, Sep 17, 2008 at 5:01 PM, Rick Burnett wrote:

> Because of this, I'd like to just eliminate JS completely as our source

> material is just going to keep increasing. Once the new SDK comes out, I am

> just going to write an external as I am comfortable with Xcode as well and

> think the compute savings will be 10 fold.

If you're going for maximum efficiency it's always a good idea to write an

external I guess. An alternative approach would be to use jit.gl.lua and

draw to a pwindow. Lua is much more efficient than JS to start with, and

jit.gl.lua has direct bindings with OpenGL through the LuaGL library. I

wouldn't be surprised if the savings with Lua would be >10 fold already.

On Wed, Sep 17, 2008 at 5:01 PM, Rick Burnett  wrote:

>
>
> Because of this, I'd like to just eliminate JS completely as our source
> material is just going to keep increasing.  Once the new SDK comes out, I am
> just going to write an external as I am comfortable with Xcode as well and
> think the compute savings will be 10 fold.
>
>

If you're going for maximum efficiency it's always a good idea to write an
external I guess. An alternative approach would be to use jit.gl.lua and
draw to a pwindow. Lua is much more efficient than JS to start with, and
jit.gl.lua has direct bindings with OpenGL through the LuaGL library. I
wouldn't be surprised if the savings with Lua would be >10 fold already.

I've contemplated some other schemes as such, but at looking at the code I'd have to write for not only a file browser, but library management system, I felt coding in Max for that sort of function was overly cumbersome and easily prone for me to make mistakes. Having now written HUGE max applications, I am starting to divide out what I believe is best to do in max, and what is best to do outside of max, not only from an implementation or efficiency perspective, but from power perspective.

To put it a step further, I'd like to reduce the complexity of my max application in the areas where max is not really helping me. That way, the majority of my connectivity is more straightforward, and for me, mostly dealing with the audio and video aspects and abilities.

I'm sure it's probably a deficiency on my part, but when doing certain functions like UI work, line-by-line code works the best for me on a -per widget- level with interconnects done in max. Best of both world approach.

But, thank you for your suggestions. I will definitely keep that in mind. I have a lot of reorganization planned as I have upgraded to Max5 and can now have 2 separate views so things can be organized NOT for UI purposes! That in itself is going to be a HUGE task that I am sure I will break things.

I've contemplated some other schemes as such, but at looking at the code I'd have to write for not only a file browser, but library management system, I felt coding in Max for that sort of function was overly cumbersome and easily prone for me to make mistakes.  Having now written HUGE max applications, I am starting to divide out what I believe is best to do in max, and what is best to do outside of max, not only from an implementation or efficiency perspective, but from power perspective.

To put it a step further, I'd like to reduce the complexity of my max application in the areas where max is not really helping me.  That way, the majority of my connectivity is more straightforward, and for me, mostly dealing with the audio and video aspects and abilities.

I'm sure it's probably a deficiency on my part, but when doing certain functions like UI work, line-by-line code works the best for me on a -per widget- level with interconnects done in max.  Best of both world approach.

But, thank you for your suggestions.  I will definitely keep that in mind.  I have a lot of reorganization planned as I have upgraded to Max5 and can now have 2 separate views so things can be organized NOT for UI purposes!  That in itself is going to be a HUGE task that I am sure I will break things.


On Thu, Sep 18, 2008 at 9:05 PM, Rick Burnett wrote:

> I've contemplated some other schemes as such, but at looking at the code

> I'd have to write for not only a file browser, but library management

> system, I felt coding in Max for that sort of function was overly cumbersome

> and easily prone for me to make mistakes. Having now written HUGE max

> applications, I am starting to divide out what I believe is best to do in

> max, and what is best to do outside of max, not only from an implementation

> or efficiency perspective, but from power perspective.

> To put it a step further, I'd like to reduce the complexity of my max

> application in the areas where max is not really helping me. That way, the

> majority of my connectivity is more straightforward, and for me, mostly

> dealing with the audio and video aspects and abilities.

I know exactly what you mean. I stopped writing HUGE patches in *just* Max

3 years ago because I feel its not where the software's strengths are. In my

experience you end up with either a big mess, something which drains your

cpu, becomes unreliable, unmanageable, non-responsive or very hard to debug.

In my case all of them together. Max is great at certain things, and not so

great at other things. It takes some experience and time to learn when to

I believe that anyone doing serious stuff in Max should lean how to program

in a procedural or object oriented language. Certain things, which are an

absolute nightmare to program in max, are fairly trivial to do in other

programming languages. The other way around is also true of course.

Writing externals can be dangerous though. Once you get the hang of it the

possibilities become literally endless, so it's really easy to loose

yourself in it. When I started with Max a few years ago i didn't know

anything about programming. Now my bookshelf contains more then 10 books

about C++ alone, and I've now been working on this "amazing new awesome

thing" for months straight. I'm having a real hard time dragging myself back

to doing creative things again, which really frustrates me. Being creative

What am I rambling on about... this is nothing new for a lot of people. I

just wanted to warn you, although I'm pretty sure it won't make any

On Thu, Sep 18, 2008 at 9:05 PM, Rick Burnett  wrote:

>
> I've contemplated some other schemes as such, but at looking at the code
> I'd have to write for not only a file browser, but library management
> system, I felt coding in Max for that sort of function was overly cumbersome
> and easily prone for me to make mistakes.  Having now written HUGE max
> applications, I am starting to divide out what I believe is best to do in
> max, and what is best to do outside of max, not only from an implementation
> or efficiency perspective, but from power perspective.
>
> To put it a step further, I'd like to reduce the complexity of my max
> application in the areas where max is not really helping me.  That way, the
> majority of my connectivity is more straightforward, and for me, mostly
> dealing with the audio and video aspects and abilities.
>
>

I know exactly what you mean. I stopped writing HUGE patches in  *just* Max
3 years ago because I feel its not where the software's strengths are. In my
experience you end up with either a big mess, something which drains your
cpu, becomes unreliable, unmanageable, non-responsive or very hard to debug.
In my case all of them together. Max is great at certain things, and not so
great at other things. It takes some experience and time to learn when to
step over to the dark side.

I believe that anyone doing serious stuff in Max should lean how to program
in a procedural or object oriented language. Certain things, which are an
absolute nightmare to program in max, are fairly trivial to do in other
programming languages. The other way around is also true of course.

Writing externals can be dangerous though. Once you get the hang of it the
possibilities become literally endless, so it's really easy to loose
yourself in it. When I started with Max a few years ago i didn't know
anything about programming. Now my bookshelf contains more then 10 books
about C++ alone, and I've now been working on this "amazing new awesome
thing" for months straight. I'm having a real hard time dragging myself back
to doing creative things again, which really frustrates me. Being creative
is what Max is all about.

What am I rambling on about... this is nothing new for a lot of people. I
just wanted to warn you, although I'm pretty sure it won't make any
difference:)

I definitely agree with you. The whole reason I came to Max in the first place was my frustration with Native Instruments and the fact if I create something great in Reaktor, the only people who can enjoy it are those with Reaktor. Even further, if I wanted to recoupe some expenses from my development time, not gonna happen there.

I downloaded Max and instantly fell in love with it. My first plugin I wrote, PAEIN, a universal panner, I released for free all over the Internet. THIS was why I liked Max, and Cycling 74.

I've written plugins in AU, LADSPA, DirectX (I used to be a PC guy, but now I am a Mac guy) and know what you mean. There are pluses and minuses to each language. When I saw I could do Java and Javascript, I used both in my application.

This is why I am not afraid, but, know that once you go into external land, it's gets harder to debug certain things, provided what level of detail C74 gives us into the API and their restrictions/intents/etc. However, given the track record of C74, I know they are VERY proficient and helpful on giving you what you need to get something done. Which is why I give them my money :)

The fact that you CAN do this is amazing. You can't link externals to Reaktor.

Another thing I love about Max is OSC. I've done some large projects with multiple programs talking together through OSC and we've had nothing but success with this!

I am hoping to release a version of my program this year, so hopefully the SDK comes soon :)

I definitely agree with you.  The whole reason I came to Max in the first place was my frustration with Native Instruments and the fact if I create something great in Reaktor, the only people who can enjoy it are those with Reaktor.  Even further, if I wanted to recoupe some expenses from my development time, not gonna happen there.

I downloaded Max and instantly fell in love with it.  My first plugin I wrote, PAEIN, a universal panner, I released for free all over the Internet.  THIS was why I liked Max, and Cycling 74.

I've written plugins in AU, LADSPA, DirectX (I used to be a PC guy, but now I am a Mac guy) and know what you mean.  There are pluses and minuses to each language.  When I saw I could do Java and Javascript, I used both in my application.

This is why I am not afraid, but, know that once you go into external land, it's gets harder to debug certain things, provided what level of detail C74 gives us into the API and their restrictions/intents/etc.  However, given the track record of C74, I know they are VERY proficient and helpful on giving you what you need to get something done.  Which is why I give them my money :)

The fact that you CAN do this is amazing.  You can't link externals to Reaktor.

Another thing I love about Max is OSC.  I've done some large projects with multiple programs talking together through OSC and we've had nothing but success with this!

I am hoping to release a version of my program this year, so hopefully the SDK comes soon :)


Max5 External for file selection, suggestions?