Roth

While I am not new to Java (but I am coming back from a ~5 year hiatus), but I am completely new to using it in Max.

I made my first MXJ over the weekend to parse the input of my BCF2000. Currently, the object channel info in the middle inlet along with CC#/value info from [midiparse] in the first inlet and creates a namespace of sorts to use with [forward] to send out the values.

Without arguments or attributes, my MXJ listens for "knobs" on CC#21-29 and "sliders" on CC#31-39 both on channels 1-8. In this default configuration examples of a namespace would be as follows:

CC# 23, Val 95, Ch 1 would send "95" to the matching [receive] named one-k3

CC# 31, Val 95, Ch 4 would send "95" to the matching [receive] named four-s1

In the example patch I have posted, you will see that there is an abstraction included--[rm.bcfr]--that handles return input to the MXJ from the interface. The namespace is applied via arguments to [rm.bcfr]. Using the two examples above, matching [rm.bcfr] objects would be setup as follows:

I realize that this simple object probably runs fast enough for my purposes, but I had some efficiency questions I was wondering about to think about for future patches.

1. If you look at the source, you will see that I use the smallest variable sizes when possible and as a result do a bit of typecasting. Does typecasting in java represent more processor overhead at runtime? or is that just a compiletime thing to let the compiler know you are aware of possible precision loss?

2. Is storing the channel variable through a separate inlet and method than is used to parse the CC#/value info asking for trouble? or can I rely on the timing to work out as needed the way I show things set up in my example maxpat.

3. Am I crossing the JVM barrier too much? Would it be faster to pack the CC#/value/Ch info into a list first and send it to one inlet and one method? Same for output for [midiout] in the right inlet, would it be faster to send a list out of the MXJ and then use [unpack 0 0 0] before [midiout]?

4. I figured using [midiparse] instead of making the MXJ listen for data from [midiin] would be more efficient since I would need less variables and wouldn't be crossing the JVM barrier for non CC information.

5. Is [timer] accurate enough to test different set up options (e.g. using MXJ to do the MIDI parsing versus [midiparse].

If you notice anything else I should do differently, let me know.

I made my first MXJ over the weekend to parse the input of my BCF2000.  Currently, the object channel info in the middle inlet along with CC#/value info from [midiparse] in the first inlet and creates a namespace of sorts to use with [forward] to send out the values.

Without arguments or attributes, my MXJ listens for "knobs" on CC#21-29 and "sliders" on CC#31-39 both on channels 1-8.  In this default configuration examples of a namespace would be as follows:

In the example patch I have posted, you will see that there is an abstraction included--[rm.bcfr]--that handles return input to the MXJ from the interface.  The namespace is applied via arguments to [rm.bcfr].  Using the two examples above, matching [rm.bcfr] objects would be setup as follows:

1. If you look at the source, you will see that I use the smallest variable sizes when possible and as a result do a bit of typecasting.  Does typecasting in java represent more processor overhead at runtime? or is that just a compiletime thing to let the compiler know you are aware of possible precision loss?

2.  Is storing the channel variable through a separate inlet and method than is used to parse the CC#/value info asking for trouble? or can I rely on the timing to work out as needed the way I show things set up in my example maxpat.

3. Am I crossing the JVM barrier too much?  Would it be faster to pack the CC#/value/Ch info into a list first and send it to one inlet and one method?  Same for output for [midiout] in the right inlet, would it be faster to send a list out of the MXJ and then use [unpack 0 0 0] before [midiout]?

my-first-mxj-and-some-efficiency-questions

Hi, i'm not an expert but i think i can answer to your question 3 :

Crossing the "JVM barrier" by sending a variable or an int/float array thru an outlet takes 1 microsecond on my MBP 2,2Ghz (it was taking around 4 microsecond on my old Powerbook at 800 Mhz).

So you have to calculate if it's signifiant in your case. I'm not really sure that it is, when using midi. To transmit midi notes you need precision of few milliseconds, let's say 2 millisecond (if you're a very good drummer :-) ), and, 2 millisec = 20000 microseconds... plus i heard that the usual speed for midi interface is not more than 1Mhz... and the period of 1 Mhz is one microsecond, so it should be fine. But if, one day, you work with lots of ethernet sensors (the case for me), you could consider this "JVM barrier" when writing java code.

Be Carefull about arrays of "Atom" : While sending an array of int[] or float[] is crossing the "JVM barrier" just one time, an array of Atom is crossing the "JVM barrier" for each value. So everytime that you need the best efficiency to pass lots of numerical datas to max, you should use theses methods :

outlet(int idx, String msg,int[] values);

outlet(int idx, String msg,float[] values);

outletHigh(int idx, String msg,int[] values);

outletHigh(int idx, String msg,float[] values);

(... but i think it only transmit the 1024 first values, so in the case that you need to transmit more, at one time, you should use MSP.buffer.poke method or even CopyArrayToVectorPlanar with jitter method.)

I only tested for outlets, not for inlets, so i don't know what really happen on int[] thru inlets, if it's crossing the "JVM barrier" only one time, or for each value of the max list going... you'll have to test it )

I made some efficiency tests, a while ago, and there were a discussion on this theme with interesting remarques from Joshua K C from Cycling, the outlet methods just above were implemented in max, just after this discussion. If it interest you:

https://cycling74.com/forums/index.php?t=msg&goto=55540&rid=2682&S=c99c8ef5033c139c28e669eafc8cb65c

Crossing the "JVM barrier" by sending a variable or an int/float array thru an outlet takes 1 microsecond on my MBP 2,2Ghz (it was taking around 4 microsecond on my old Powerbook at 800 Mhz). 

So you have to calculate if it's signifiant in your case. I'm not really sure that it is, when using midi. To transmit midi notes you need precision of few milliseconds, let's say 2 millisecond (if you're a very good drummer :-) ), and, 2 millisec = 20000 microseconds...  plus i heard that the usual speed for midi interface is not more than 1Mhz... and the period of 1 Mhz is one microsecond, so it should be fine. But if, one day, you work with lots of ethernet sensors (the case for me), you could consider this "JVM barrier" when writing java code.

outlet(int idx, int[] values);
outlet(int idx, float[] values);
outletHigh(int idx, int[] values);
outletHigh(int idx, float[] values);
outlet(int idx, String msg,int[] values);
outlet(int idx, String msg,float[] values);
outletHigh(int idx, String msg,int[] values);
outletHigh(int idx, String msg,float[] values);

I made some efficiency tests, a while ago, and there were a discussion on this theme with interesting remarques from Joshua K C from Cycling, the outlet methods just above were implemented in max, just after this discussion. If it interest you:
https://cycling74.com/forums/index.php?t=msg&goto=55540&rid=2682&S=c99c8ef5033c139c28e669eafc8cb65c

My First MXJ and some efficiency questions