• check failed:no matching expression


    Jan 23 2008 | 10:24 pm
    I found this thread:
    Which suggests this message involves:
    1. Some object is sending information out an outlet in some thread other than the scheduler or low priority threads.
    2. Memory has been corrupted by some object.
    I'll post a patch right after this. I'm trying to cut out all of the extra objects. The patch will seem weird since I've hacked out most of the useful function.
    The only 3rd party external is cambio~, by Matt Wright. It's here:
    Is this a problem where cambio~ is sending its message in the audio thread?
    To reproduce, open the patch and turn on audio. No errors. Open the gate to with the toggle. Errors.
    Intel iMac; 10.4.11; Max 4.6.3
    tx,
    mz

    • Jan 23 2008 | 10:25 pm
      The patch:
    • Jan 23 2008 | 11:16 pm
      FWIW, I don't have cambio~ installed and I don't get the "check failed" message.
      -- P.
    • Jan 24 2008 | 1:48 am
      No error here, _with_ cambio~ installed
      MacBook Pro, Max/MSP 4.6.3, OS X 10.4.11
    • Jan 24 2008 | 1:59 am
      Quote: kjg wrote on Thu, 24 January 2008 02:48 ---------------------------------------------------- > No error here, _with_ cambio~ installed
      excuse me, that was before I saw that the gate had to be opened for printing. With cambio~ installed, same error here
    • Jan 24 2008 | 7:58 am
      mzed schrieb: > The patch:
      Works fine here on a PPC Powerbook.
      Btw, do you know how to open an embedded bpatcher? Maybe in this case its better to send the bpatcher seperately...
      Anyway seems to need to be checked with Matt...
      Stefan
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Jan 24 2008 | 8:26 pm
      For everyone's general interest, I put a "pipe 0" after cambio~, and that seems to have fixed the problem. The purpose of the seemingly paradoxical pipe is to move the output of cambio~ to the scheduler, rather than the audio thread.
      I'm off to try to learn to fix this in the code. Any suggestions would be helpful.
      mz
    • Jan 25 2008 | 9:05 am
      mzed schrieb: > For everyone's general interest, I put a "pipe 0" after cambio~, and > that seems to have fixed the problem. The purpose of the seemingly > paradoxical pipe is to move the output of cambio~ to the scheduler, > rather than the audio thread.
      You'd better use deferlow for that purpose. In the past at least I had problems with pipe and don't trust it if it isn't absolutely necessary. Deferlow is made for exatly that purpose. Its an object which fixes so many problems, that I don't know how maxin' was possible before it became a standard object... ;-)
      Stefan
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Jan 25 2008 | 7:18 pm
      Quote: Stefan Tiedje wrote on Fri, 25 January 2008 01:05 ---------------------------------------------------- > mzed schrieb: > > For everyone's general interest, I put a "pipe 0" after cambio~, and > > that seems to have fixed the problem. The purpose of the seemingly > > paradoxical pipe is to move the output of cambio~ to the scheduler, > > rather than the audio thread. > > You'd better use deferlow for that purpose. In the past at least I had > problems with pipe and don't trust it if it isn't absolutely necessary. > Deferlow is made for exatly that purpose. > Its an object which fixes so many problems, that I don't know how maxin' > was possible before it became a standard object... ;-) >
      That seems pretty extreme to me. Because accurate timing is important, I'm running this patch with overdrive on, scheduler in audio interrupt, and low (
      I should add that putting the scheduler in audio interrupt also eliminated my error with cambio~.
      Maybe this belongs in the dev forum now; I'll let the moderator decide. All of this problem is a result of calling output_float() in the perform method of an MSP object. Most of what I've found in the forum and in the manual says that this is a bad idea, and obviously I've run into problems. Matt Wright has described Ben Neville's forum posts on this topic as "bullying", which I think is harsh. But I agree that there needs to be a little more content beyond "you shouldn't do that." cambio~ limits itself to outputting 3 events per vector, and we have ample means to put those events in either the queue or the scheduler after the fact, so why not output them in the most timing-sensitive way possible? Moving from the signal thread to either event thread is pretty crummy for programmers. I'm somewhat reassured by throwing the scheduler in audio interrupt, but having to instantiate all these clocks to get events from signals is disconcerting at best.
      Pardon my rant. I'm sure this is a known issue for cycling developers. I'm off to work in SuperCollider for a while.
      mz
    • Jan 26 2008 | 4:55 pm
      mzed schrieb: > That seems pretty extreme to me. Because accurate timing is > important, I'm running this patch with overdrive on, scheduler in > audio interrupt, and low ( > my messages into the scheduler. Unless the scheduler is backlogging > (and I wish I had a tool to see this), then that stack will be > serviced every signal vector. deferlow will dump things to the back > of the queue, which is serviced at a lower priority.
      I recall an explanation from JCK (the author of deferlow) who claimed sending a bang through [delay 0] does exactly the same as sending it through deferlow. I don't know if this would be true for pipe as well...
      Maybe some C74 gurus who know the sources can shed some light on it...
      Stefan
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com