rewire~: queue stepped on itself ?

    ComfortableInClouds
    Aug 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.
    • radiowonderland@gmail.com
      Aug 18 2008 | 4:32 am
      Hi, did you get an answer to this?
    • ComfortableInClouds
      Aug 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').
    • radiowonderland@gmail.com
      Aug 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.
    • ComfortableInClouds
      Aug 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).
    • radiowonderland@gmail.com
      Aug 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.
    • ComfortableInClouds
      Aug 18 2008 | 8:30 pm
      great :-D glad to see this issue resolved.
    • radiowonderland@gmail.com
      May 06 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?
    • radiowonderland@gmail.com
      Jun 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?
    • AudioMatt
      Jun 23 2011 | 9:41 pm
      two year bump! /using the work around.