rewire~: queue stepped on itself ?

Aug 17, 2008 at 2:52am

rewire~: queue stepped on itself ?

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.

#39317
Aug 18, 2008 at 4:32am

Hi, did you get an answer to this?

#138252
Aug 18, 2008 at 7:47am

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’).

#138253
Aug 18, 2008 at 1:23pm

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.

#138254
Aug 18, 2008 at 7:45pm

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).

#138255
Aug 18, 2008 at 8:06pm

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.

#138256
Aug 18, 2008 at 8:30pm

great :-D glad to see this issue resolved.

#138257
May 6, 2009 at 12:49am

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?

#138258
Jun 20, 2009 at 10:20pm

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?

#138259
Jun 23, 2011 at 9:41pm

two year bump! /using the work around.

#138260

You must be logged in to reply to this topic.