dbudde

Yes, I get that. And thank you for your thoughts on this.

Peter, I can deal with workarounds. That's not what is being debated here.

One last thing... That's not correct. C4 and C3 would both return 60 for middle C: Middle C by the name of C3 = MIDI Note #60 Middle C by the name of C4 = MIDI Note #60 HTH. You misinterpreted my comment. To paraphrase: If the display preference is set to C4 for middle C, then MIDI.noteNuber("C4") should return 60. If the display preference is set to C3 for middle C, then MIDI.noteNumber("C4") should return 72.

Peter, for the best real time performance, pitch should always be designated as a number. Integer computations are far faster than text manipulation. Text should only be used for User Interface (non-real time) purposes.

oscwilde, Thanks for your thoughts on this matter. One final thought to beat this to death... If MIDI.noteName(60) always provides the same answer, what is the point of this function? There is never a need to execute it. So I maintain the intent was to provide a different answer based on the preference setting and the implementation currently has a bug because it provides the correct result in one case and the same/wrong result in the other case.

oscwilde, I agree that the real time part of Scripter shouldn't be affected. But Scripter does provide some level of API that allows one to build User Interface display information when utilizing the Scripter plugin. I'm thinking specifically of Javascript MIDI object functions: MIDI.noteNumber(string name) and MIDI.noteName(number pitch). These should in my opinion return a result that is consistent with the display preference for middle C. So for instance, MIDI.noteNumber("C4") should return 60 if the middle C display preference is set to C4 and return 72 if middle C is set to C3. This would allow one to build consistent UI between Scripter and other plugins that do this same translation. Otherwise, it is confusing for the user unless the user specifies C3 as the display preference for middle C. The UI part of Scripter does not run in real time. It is invoked for the parameterChanged() function. This happens for instance when a user clicks on a menu item in the parameter section of the Scripter interface. The functions mentioned above run in this function so there is no problem returning results that require translation.

OK, we can take this offline if you like. I built a much simplified mechanism which works for me. My needs are sparse compared to what you are trying to do, so you could well be right. Feel free to contact me privately if you want to discuss specifics beyond what is posted above.

I don't understand this requirement for a separate midi device. Since you already have an environment object doing whatever it is doing, can't you just transform the keyswitch octave on the main keyboard controller into a CC number and then feed that to a smart control that converts it to the articulationID? For instance, in the following image, a transformer is converting octave C0..B0 into CC100,0..CC100,11. Then your smart control can convert the CC100 values into the articulationID.

I've filed a bug report so we'll see whether Apple thinks it's a bug or a feature.

The scripter plugin interprets C3 as middle C regardless of the display preference setting which allows one to define middle C as either C3 or C4. Is this a bug or intentional?

reinstalling seems to have fixed this.

Anyone else seeing this. If you invoke Help in Logic Pro X 10.1 and then do a search, the search results are in German. If you click on a result, then it reverts to English. Normal help (non-search) is all English.

Excellent, they fixed the headless display problem.

Mano, you might find this useful for your rack mount. http://www.h-sq.com/products/minimount/index.html

Reported.