alberto-bernal

I need to get the value of all the faders/knobs of my midi controller Evolution UC33e, which has a function to do snapshot of all these values. When trying to become this all values in max, I just receive some of then, about 1/3 of all, almost always the same controllers. I show the midi input on the computer using the app midi monitor and actually the midi device is sending all the values, but max isn't receiving them at all. 

Could it be that max is unable to manage so many (37) controller values sent at the same time? Or what is actually happening? Is there somehow a solution/alternative?

Hi,
  I need to get the value of all the faders/knobs of my midi controller Evolution UC33e, which has a function to do snapshot of all these values. When trying to become this all values in max, I just receive some of then, about 1/3 of all, almost always the same controllers. I show the midi input on the computer using the app midi monitor and actually the midi device is sending all the values, but max isn't receiving them at all. 
 Could it be that max is unable to manage so many (37) controller values sent at the same time? Or what is actually happening? Is there somehow a solution/alternative?
  Thank you very much for your tips,

problems-becoming-midi-snapshots

If you're using ctlin, I think it may have difficulty with multiple messages in the same MIDIPacket, which is the way the OS X built-in USB MIDI driver likes to pack them if they're received at the same time.

Try using midiin connected to midiparse.


Thank you. I think is exactly what you say, with midiparse is everything working. With individual ctlins only 4 channels of each controller number arrive.

Anyway it is very uncomfortable to distribute the information of 38 controllers using midiparse, it would be fine, if this issue could be fix in next versions of max.

Thank you. I think is exactly what you say, with midiparse is everything working. With individual ctlins only 4 channels of each controller number arrive.
Anyway it is very uncomfortable to distribute the information of 38 controllers using midiparse, it would be fine, if this issue could be fix in next versions of max.
 Thanks,

interesting, I have the same UC-33e and never thought to use the Snapshot to record the values, a good idea. Good to know that there were some problems and that midiparse was the solution. I'll have to try it on XP and see if the snapshot works with ctlin on the Windows side.

Probably it is tough for the ctlins to parse through all the data if it comes in as one big packet... didn't consider that. If the ctlin could somehow be fixed for this particular problem, it would give some more flexibility than using midiin / midiparse (easier to set channels / controller numbers on the fly).

interesting, I have the same UC-33e and never thought to use the Snapshot to record the values, a good idea. Good to know that there were some problems and that midiparse was the solution.  I'll have to try it on XP and see if the snapshot works with ctlin on the Windows side.

Yeah. The ctlin deficiency is one of the reasons I'm working on dedicated CoreMIDI objects that totally bypass Max MIDI drivers and talk directly to CoreMIDI.

And I want to do more flexible filtering stuff at the object, based on the raw MIDI numbers, ie:

[cm.in port 176 0/32] - CC0 or CC32 on ch1

[cm.in port 128-129/144-145 !60-83] - note off/on on ch1-2, excluding notes 60-83

[cm.in port 178 0 * 178 32] - CC0 on ch3, immediately followed by CC32 on ch3

[cm.in port 176-191!179 64 66/2] CC64 on any channel except 4, values 66 or 2 only

The other reason is that I want to be able to "hide" ports from subsequently-opened apps, and this seems to be crashing randomly if used with Max's own MIDI drivers active, but works fine if those are removed and CoreMIDI is used directly.

Yeah. The ctlin deficiency is one of the reasons I'm working on dedicated CoreMIDI objects that totally bypass Max MIDI drivers and talk directly to CoreMIDI. 

The other reason is that I want to be able to "hide" ports from subsequently-opened apps, and this seems to be crashing randomly if used with Max's own MIDI drivers active, but works fine if those are removed and CoreMIDI is used directly.


> If you're using ctlin, I think it may have difficulty with multiple

> messages in the same MIDIPacket, which is the way the OS X built-in

> USB MIDI driver likes to pack them if they're received at the same

> Cycling 74: can we consider this a bug?

If ctlin failes and midiin works, this is clearly indicating a bug.

(Its not a fault of the drivers, as they comply to the Midi specs which 

I wouldn't mind some sort of bugzilla on the cycling site, that would 

allow users to search there for bugs which are filed already, see the 

status and priority and insert new reports. It would also force every 

report to comply to the guidelines which are essential for fixing things...

While filing things it can already search for answers (not every problem 

It could also directly lead to incremental updates if things got fixed...

I just want to express my compliance to the last post of this thread. 

Its not about putting pressure on those who usually fix bugs fast 

anyway, but sometimes its just easier to get around if you just know its 

filed as a bug, then I can easily stop worrying about it...

Eventually a simple reply to the post I am replying now, indicating that 

its filed would help already... (Or if its not considered a bug express 

this, then we know its better to use the workaround with midiin than 

John Pitcairn schrieb:
> If you're using ctlin, I think it may have difficulty with multiple
> messages in the same MIDIPacket, which is the way the OS X built-in
> USB MIDI driver likes to pack them if they're received at the same
> time.
>
> Cycling 74: can we consider this a bug?

If ctlin failes and midiin works, this is clearly indicating a bug.
(Its not a fault of the drivers, as they comply to the Midi specs which 
allow running status...)

I wouldn't mind some sort of bugzilla on the cycling site, that would 
allow users to search there for bugs which are filed already, see the 
status and priority and insert new reports. It would also force every 
report to comply to the guidelines which are essential for fixing things...

While filing things it can already search for answers (not every problem 
is a bug... ;-)

It had been discussed though: http://tinyurl.com/2ppplc

I just want to express my compliance to the last post of this thread. 
Its not about putting pressure on those who usually fix bugs fast 
anyway, but sometimes its just easier to get around if you just know its 
filed as a bug, then I can easily stop worrying about it...

Eventually a simple reply to the post I am replying now, indicating that 
its filed would help already... (Or if its not considered a bug express 
this, then we know its better to use the workaround with midiin than 
waiting for a fix...)

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

Quote: Stefan Tiedje wrote on Sat, 08 September 2007 01:13

----------------------------------------------------

> (Its not a fault of the drivers, as they comply to the Midi 

The MIDI hardware specs do, but CoreMIDI doesn't allow running status internally, at least not in a MIDIPacket - that's explicitly stated in MIDIServices.h.

If a device sends a 14-bit CC message to the built-in USB MIDI driver using running status:

And as far as my testing goes, what you'll get using other USB MIDI drivers is either two MIDIPackets in a single MIDIPacketList:

Or two MIDIPacketLists, each containing a single MIDIPacket as above.

Quote: Stefan Tiedje wrote on Sat, 08 September 2007 01:13
----------------------------------------------------
> John Pitcairn schrieb:
> (Its not a fault of the drivers, as they comply to the Midi 
> specs which allow running status...)

If a device sends a 14-bit CC message to the built-in USB MIDI driver using running status:
176 0 64 32 127

What you'll get in the MIDIPacket is:
176 0 64 176 32 127

> The MIDI hardware specs do, but CoreMIDI doesn't allow running status

> internally, at least not in a MIDIPacket - that's explicitly stated

MidiPacket seems to be a programmers talk its not part of the midi spec, 

> If a device sends a 14-bit CC message to the built-in USB MIDI driver

> What you'll get in the MIDIPacket is: 176 0 64 176 32 127

Which is the same information wise... Any Midi program/device should do 

> And as far as my testing goes, what you'll get using other USB MIDI

> drivers is either two MIDIPackets in a single MIDIPacketList:

> Or two MIDIPacketLists, each containing a single MIDIPacket as above.

Both should not make any difference... Its two events, no matter if they 

come together or one after another... This points to a bug in ctlin, 

there it should be fixed, not by changing drivers...

John Pitcairn schrieb:
> The MIDI hardware specs do, but CoreMIDI doesn't allow running status
> internally, at least not in a MIDIPacket - that's explicitly stated
> in MIDIServices.h.

MidiPacket seems to be a programmers talk its not part of the midi spec, 
there are only messages...

> If a device sends a 14-bit CC message to the built-in USB MIDI driver
> using running status: 176 0 64 32 127
>
> What you'll get in the MIDIPacket is: 176 0 64 176 32 127

Which is the same information wise... Any Midi program/device should do 
exactly the same with it...

> And as far as my testing goes, what you'll get using other USB MIDI
> drivers is either two MIDIPackets in a single MIDIPacketList:
>
> 176 0 64 176 32 127
>
> Or two MIDIPacketLists, each containing a single MIDIPacket as above.

Both should not make any difference... Its two events, no matter if they 
come together or one after another... This points to a bug in ctlin, 
there it should be fixed, not by changing drivers...

problems becoming midi snapshots