mzed

https://cycling74.com/forums/index.php?t=msg&goto=95748&rid=0&S=6b1c4a2cd0e2120ba1b2699206f22448

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.

1. Some object is sending information out an outlet in some thread 
other than the scheduler or low priority threads.

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:

To reproduce, open the patch and turn on audio.  No errors.  Open the gate to with the toggle.  Errors.  

check-failedno-matching-expression

FWIW, I don't have cambio~ installed and I don't get the "check failed" message.

MacBook Pro, Max/MSP 4.6.3, OS X 10.4.11 

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

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


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

Btw, do you know how to open an embedded bpatcher? Maybe in this case 
its better to send the bpatcher seperately...

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

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.

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.

> 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,

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

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

Quote: Stefan Tiedje wrote on Fri, 25 January 2008 01:05

> > 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,

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

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

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.

> That seems pretty extreme to me. Because accurate timing is

> important, I'm running this patch with overdrive on, scheduler in

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

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

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


• check failed:no matching expression