Hello Folks!
Finally I got the I-Cube X, firmware 4.1, gforce2d, turn sensor and some other infrared sensors ( acroname ).
The Editor didn't run in 9.2.2, but runs ok in Jaguar.
Tried several times a LOT of configurations, some things weird happened:
setup 1
Cube G4, MAX 4.2b12 os 9.2.2, Midisport 2x2, I-cube in Standalone mode.
The midi receive status in the interface flashed, but nothing happened.
setup 2
Tibook 667
Jaguar 10.2.3, MAX 4.2b12, Midisport 2x2, I-cube in Standalone mode.
The midi receive status in the interface flashed, but nothing happened.
Tested the same midi interface with another midi controller....
WORKED!!??!!
Tibook 500
OS 9.2.2, Logic Audio 4.7.3, Hammerfall midi interface, I-cube in Standalone mode.
WORKED!!!!
when switched to MAX
nothing happened, but the midi input in the interface flashes accordingly...
then turned the I-cube off, and on again
WORKED!!!!
Back to setup 2
nothing happened, but turned the I-cube off and on again..
WORKED!!!!!
Any further ideas about what could happened??
I need a reliable setup to work here, and paid for it... hope to solve this soon..
best wishes
christian eduardo
rio de janeiro - brasil
Icube X problems and solutions
Moderator: Tech
Icube X problems and solutions
Hi,
Looks like a MIDI running status problem. Here is a solution previously posted:
The problem you are having may be related to the running status mode on the digitizer when it is in Stand Alone mode. This running status mode prevents the digitizer from repeating continuously the midi status mode header (note-on, pitch bend, control change, ...). So, it sends the running status mode once (note-on on midi channel 1 for example) then sends the data related to this mode (the note number and the velocity) until a change of status (note-number, velocity, note, velo, note, velo, ...). If you started the digitizer before your midi application (or if you connected it to your midi equipment that was powered after the digitizer was) then the digitizer could have sent the running status before you had the application running, so the application (or midi equipment) doesn't know the running status related to the incoming data.
To avoid this problem you could use a dummy sensor (a sensor used to reset the running status mode) to send a midi note-off on an unused midi channel for example. Say you use input 32 as a dummy sensor (you could leave the input unconnected with no sensors as the digitizer would sample noise on this input) and program it to send midi note-off on channel 1 note number 1. This would send a change of midi status to note-off channel 1 when the input 32 is triggered from the sensor (or from noise), hence bringing back the midi status to your midi equipment/software. So when you activate any of the valid sensors (the ones you actually want to use) the midi running status will be changed to whatever you programmed it to send (except midi note-off on channel 1 in our example).
Regards.
--
Technical Support
Infusion Systems Ltd.
Looks like a MIDI running status problem. Here is a solution previously posted:
The problem you are having may be related to the running status mode on the digitizer when it is in Stand Alone mode. This running status mode prevents the digitizer from repeating continuously the midi status mode header (note-on, pitch bend, control change, ...). So, it sends the running status mode once (note-on on midi channel 1 for example) then sends the data related to this mode (the note number and the velocity) until a change of status (note-number, velocity, note, velo, note, velo, ...). If you started the digitizer before your midi application (or if you connected it to your midi equipment that was powered after the digitizer was) then the digitizer could have sent the running status before you had the application running, so the application (or midi equipment) doesn't know the running status related to the incoming data.
To avoid this problem you could use a dummy sensor (a sensor used to reset the running status mode) to send a midi note-off on an unused midi channel for example. Say you use input 32 as a dummy sensor (you could leave the input unconnected with no sensors as the digitizer would sample noise on this input) and program it to send midi note-off on channel 1 note number 1. This would send a change of midi status to note-off channel 1 when the input 32 is triggered from the sensor (or from noise), hence bringing back the midi status to your midi equipment/software. So when you activate any of the valid sensors (the ones you actually want to use) the midi running status will be changed to whatever you programmed it to send (except midi note-off on channel 1 in our example).
Regards.
--
Technical Support
Infusion Systems Ltd.