Forums > MaxMSP

rewire~: queue stepped on itself ?

August 17, 2008 | 2:52 am

i received this error message while sending midi data to reason through the rewire~ object. what does it mean exactly and how might i avoid it? i assume it means that there was too much midi information being sent to reason at one time, so i was curious if there might be a way to filter my midi messages as to avoid this error from happening. how much should i filter? i assume this is like in max, when you need to flush the note out object, but i’m not sending midi info through noteout (using midi messages to [rewire~]) so im not sure how i could ‘flush’ this information. thanks for the help.


August 18, 2008 | 4:32 am

Hi, did you get an answer to this?


August 18, 2008 | 7:47 am

did not. hopefully a c74 guy will see this later today and can help out. i also contacted propellerhead about this; see what they say. I tried using a speedlim object to limit the midi info that got through – but at a speedlim value of 32nd notes at 100 BPM (75 ms), i still got the message after a rather short period of time. ive started sending my midi info through the computer’s built in midi channels (maxMSP1, maxMSP2, IACDriver) but that only allows me 3 voices for midi, as opposed to the 65 available to me through the midi message to [rewire~]. but ive encountered no problems with midi through this method (since it’s sent through a noteout object, one can always just ‘flush’).


August 18, 2008 | 1:23 pm

I’ll be trying those non-rewire~ MIDI buses today also. But I don’t see how that limits us to three (voices, streams, whatever). There are after all 16 MIDI channels, and Reason offers buses A, B, C, and D, so that would be 16 X 4 = 64. The Reason manual says that Rewire is "preferred"; I wonder why.


August 18, 2008 | 7:45 pm

my mistake :-D, you’re right. i guess the midi message not working isn’t such a problem then. i bet reason advises one to use rewire instead so that their program can handle the midi info (tho it clearly is ineffective at that).


August 18, 2008 | 8:06 pm

Another item:

I changed my signal and I/O vectors to 512 and 512 and the errors have stopped — even after attempts to blast rewire~ with MIDI.


August 18, 2008 | 8:30 pm

great :-D glad to see this issue resolved.


May 6, 2009 | 12:49 am

Argh. Problem back again, even with vectors at 512, running on a sleek Mac Pro. Maybe the difference is that we now have a lot of OSC via UDP going in and out of Max.

rewire~: queue stepped on itself

happens after about 5 minutes. Gotta turn off audio, send "Reason" to rewire~, turn on audio again.

Anybody out there?


June 20, 2009 | 10:20 pm

I think I have a definitive fix for this problem.

Don’t use the special Max rewire~ syntax to send MIDI messages via the rewire~ object. Don’t send MIDI through the rewire~ object at all.

Use the good old virtual MIDI buses’from MaxMSP 1′ and ‘from MaxMSP 2′and assign MIDI buses ‘A’&'B’ to them in Reason.

Non-rewire~ MIDI and rewire~ audio seem to co-exist happily.

Aren’t you relieved?


June 23, 2011 | 9:41 pm

two year bump! /using the work around.


Viewing 10 posts - 1 through 10 (of 10 total)