bpatcher backward compatibility problems
I noticed that some of my Max 4 patches that use bpatchers fail to open properly. I was getting an error message like "bad header" and the bpatchers are blank. I had to open the bpatcher in Max 5 and save it as a .maxpat before it worked.
I was hoping to do a new release of my objects for Max 4 and have it work in Max 5 without doing two sets of all the patches.
I don’t think this always happens, need to investigate more. I’m not near Max right now, but I was wondering if anyone else ran into this and knows how to fix it?
I found a way to consistently reproduce this.
Steps to reproduce:
1. Unpack attached zip file and add the 3 patches to your Max 5 path
2. do NOT open any of the files in Max 5
3. Create a new patch
4. Create the object [bpatcherbugtest]
5. Right click the object and open the Help
The help patch should open, containing a bpatcher with the comment "Hello"
The bpatcher is blank. The following error prints in the Max window:
bpatcherbug.pat: can’t open, bad header.
bpatcher: bpatcher: error loading patcher bpatcherbug.pat
The reason for step 2 (in the steps to reproduce) is that once you manually open the bpatcherbug file, then everything works correctly until the next time you restart Max 5. Then it’s broken again.
This is not the only situation where this happens. It is also happening in a deeply nested patch hierarchy, with abstractions inside abstractions and bpatchers inside bpatchers. I don’t have time now but I can maybe prune it down to a simple example in a few days. But maybe this bug report will help clear up all these issues?
Any chance of this getting fixed in an incremental release? It’s preventing a lot of my Max 4 patches from working in Max 5.
Forgot to mention, in case it makes a difference:
OS X 10.5.2 running on Intel Core 2 Duo
I was able to recreate the problem on a mac book pro running OS 10.4.11
Adam Murray schrieb:
> Actual Behavior: The bpatcher is blank. The following error prints in
> the Max window: bpatcherbug.pat: can’t open, bad header. bpatcher:
> bpatcher: error loading patcher bpatcherbug.pat
I remember that I came across something like that, it didn’t bother me,
as when I saved the offending patcher in Max 5 format everything was
Quote: Stefan Tiedje wrote on Fri, 25 April 2008 12:05
> I remember that I came across something like that, it didn’t bother me,
> as when I saved the offending patcher in Max 5 format everything was
> fine again…
Except I would like to release some patches for Max 4 that also work in Max 5. I have many dozens of patches and I am still developing them, so after every change I’m supposed to then go over to Max 5 open it up there, and then save it as a .maxpat version? I don’t think so.
Maybe if there was a batch 4 -> 5 conversion tool I could live with this issue, but since there’s no Max command line it’s a little tricky (I failed at attempts to use AppleScript in the past, that language is nonsensical to me).
Or if there’s something I can change about the way I’m building my patches in Max 4, I’d do it. But I don’t see a way to work around the bug report I posted.
Quoting the C74 FAQ:
"Will my old patches work in Max 5?
We’re working to ensure that the vast majority of existing Max 4.x patches will work in Max 5 without any appreciable pain and suffering."
I would appreciate a comment from C74 to let me know whether this is something you see as a problem and intend to fix. If not, fine, but I’d like to know either way so I can come up with a strategy for Max 4/5 compatibility.
.pat text files complaining about a bad header is already fixed for the next release (later today), along with the vast majority of bug reports so far.
Thanks for the reports, folks.
Verified my bpatcher problems are gone in 5.0.1.
Extremely grateful for the really fast turn around time on these bugs. And released on a Saturday, even. Hopefully you all can relax a little now, you deserve it.