Never had that prob with 'history' object itself, only time i come close to that kind of message is when i make errors/typos defining things in codebox. Are you using codebox? If so, did you remember to define the history object first near the top of your code(and also remember when first defining it will have a capital 'H')? Can you see more about the problem in the 'Code' window within gen~? (if you're using codebox and have any codebox-related confusion, it helps to connect up the objects you want to use with regular non-codebox form, then look in the 'Code' window to see how gen~ translates it all to code and then follow that same kind of coding syntax for your own codebox version) Maybe post the patch?

Thx for the answer No codebox used Here is the patch The 4 history ops are isolated on the right in the main GEN patcher

Dont know if you can make smthg out of it, it's based on an old DSF synthesis algo and i got a little carried away with it But i got it to work quite well yesterday and today it wouldn't work anymore

Regards

interesting... i'm stumped for the most part here, but i did try removing ALL the 's' and 'r' objects(i didn't think gen~ added history/delay when using those objects, but since send~/receive~ adds delay in regular MSP, figured i'd try it). after doing that, the only error message i get is that var 'ad' is undefined(which is in your 'expr' object within the central gen subpatcher to which those 4 history objects are attached).

i probably screwed up your patch here, but just so you can take a look at the error message now, here it is:

i'd go through your original and just delete the 's' and 'r' objects and maybe de-encapsulate(keep everything in one patch and hook up history objects directly...)... there may be some bug or something causing confusion with history objects when encapsulating or using 's' and 'r'.... i'm not really sure, but once you can narrow down the error, you could then add things back in and re-encapsulate one-by-one to see what the problem is exactly. but until someone else chimes in, hopefully that can help give some further helpful info. on the problem. sorry i couldn't help you in a more exact way.

Thx again for helping You are correct about hat ad variable thing but iit was just a typo and nothing to do with the history ops, so thats not where the problem lies I ll try to clean it up and report back if i find something

@ raja Re-up this thread cause i've been checking the patch in your reply A few things were misconnected but otherwise it works as expected, seems you've nailed the problem, so thk you very much ! :-) Just in case, i've attached a "cleaned-up" version to this post

So it clearly had to do with the multiple send - receive around gen subpatches... could this be considered a bug or is it a normal feature of the history op ? I like to use all of this stuff to keep complex patches as clean as possible, so being limited by this feels a bit annoying to me

Hey! Nice Work! (glad i could help) You could try adding the send/receive objects back in at this point(make a duplicate copy of your patch first!). I don't know how it works under-the-hood, but even in XCode and other dev-environs, compilers can often trace errors to the wrong point when dealing with stuff saved to memory that causes a delay(it's as if the single-sample delay of 'history' can cause the compiler to delay where it detects an error and thus report errors where there are none while the actual error occurred before it.... hope that makes sense...). So if you can create a version that has absolutely no other errors, but then has this problem with send/receive again, then it could be a bug(add things like 's'/'r' and encapsulation one at a time and just make sure it works first before moving on to add anything else)... currently, it's hard to tell for sure if any of the objects are bugged, though.

Well I'm nowhere near a professional programmer so i have no clue how a compiler works but what you say makes sense. Like an infinite loop happening within the 1 sample inner workings of GEN I guess you can't call that a bug, indeed, it's just that nothing prevents you from making it occur when patching stuff without using a codebox Thx again Regards