I’ve been having a strange problem with mxj and my latest code abomination.
Max freezes or crashes on the first test-run _after_ I re-compile and re-instantiate the mxj.
Logout sometimes helps, and when it doesn’t a restart always does. Once I restart, the patch runs as expected.
I know it’s impossible to say exactly without a code example, but the code is pretty huge… All I’m wondering about is where I might start looking for a cure for such a problem? Any ideas about what types of routines, data structures, etc. might present this strange behavior? A garbage collection thing maybe? I have a "clear" routine that resets/clears all data structures, which I always run before I close/re-open the patch.
Are you doing any swing stuff? Are you on OS X?
hmm… I thought I replied to this yesterday, but it doesn’t seem to have posted.
Anyway, no, no swing. I’m on OS X, 10.4.6. I should mention that all of my previous experiences with hangs while working on this patch came down to problems with sflist~. Mostly related to overly ambitious preloading (too fast). I fixed that problem, and sflist~ is now calling the shots in terms of preload speed, so I can’t imagine that’s still the problem. I’ve been clearing the sflist~ before I close the patch as well, just to be safe.
Is it possible for an sfplay~ to still maintain an errant preload, even when it’s getting all its cues from one sflist~?
Mind you, I don’t see how a problem that presents itself after compiling could relate to sflist~. Dunno. Strange, as the post title suggests…
I just found this in a older thread:
>Actually if you do not recompile a class during a Max session all
>instances of that class will be loaded by the same classloader. A
>class will only be loaded by a new classloader if it changes.
Do you think maybe there’s something like this going on with my patch, only in the converse "if you _do_ recompile" situation?
The reason I’m wondering is because I just loaded up my patch as a few AU plugins in Logic, and it turns out that there’s some data creeping around between plugin instances — all plugs are getting data from the last plugin instance loaded. So obviously something’s getting passed around. VSTTDs: VST Transmitted Data.
I’ve never quite gotten my head around how data is shared/not shared bewteen instances of mxj objects in plugins. Any hints/tips? Does this seem like it might be related to earlier crashes as well?
I know, I know…
it’s kind of embarrassing how often I answer my own questions…
Anyway, I found the shared data (VSTTD) bit; a poorly placed "static" declaration.
I guess maybe this could cure the other problem, too? Dunno.
I’m still having what I think are constructor-related problems when using multiple plugin instances. Can anyone possibly simplify the "best practices" for keeping independent mxj-based plugins totally independent? I guess I’m really not sure how multiple instances of plugins interact with regard to the VM.
Okay, I can load about 5 or 6 instances of the plug, then Logic crashes on Thread 0, with the following:
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x27321e90
Thread 0 Crashed:
0 MaxPPC3.1 0x2726ecbc hashtab_store + 216
1 MaxPPC3.1 0x27275a2c reg_object_namespace_fromsym + 92
2 MaxPPC3.1 0x27275f60 object_register_unique + 84
3 MaxPPC3.1 0x271cc1b4 patcher_uniqueboxname + 44
4 MaxPPC3.1 0x271cc2f0 patcher_objectname + 32
5 MaxPPC3.1 0x271b091c typedmess_fun + 1628
6 MaxPPC3.1 0x271b004c typedmess + 84
7 MaxPPC3.1 0x271b1318 aeval + 1116
8 MaxPPC3.1 0x27198b24 bf_fastload + 636
9 MaxPPC3.1 0x271a9200 lowload_type__FPcslsP4atoms + 480
10 MaxPPC3.1 0x271a9928 fileload_extended + 160
11 MaxPPC3.1 0x271a9848 fileload_type + 76
12 MaxPPC3.1 0x272528ac xpcoll_loadentry + 52
13 MaxPPC3.1 0x27252840 xpcoll_findload + 44
14 MaxPPC3.1 0x27247940 linklist_funall + 80
15 MaxPPC3.1 0x27252734 xpcoll_loadpatchers + 72
16 MaxPPC3.1 0x2725222c xpcoll_load + 72
20 VNS_fuzzy_to_VST-build 0x02fcffa8 IntoVstPlugLib + 520
21 VNS_fuzzy_to_VST-build 0x02fcf9a8 main + 792
22 com.cycling74.PluggoAU 0x271603b4 PluggoAUEntry + 10332
23 com.cycling74.PluggoAU 0x2715df98 PluggoAUEntry + 1088
24 com.cycling74.PluggoAU 0x2715d598 dyld_stub_memchr + 655604424
25 com.cycling74.PluggoAU 0x2715dbd0 PluggoAUEntry + 120
26 …ple.CoreServices.CarbonCore 0x90bd9de4 CallComponent + 260
27 …apple.audio.units.AudioUnit 0x94250854 AudioUnitGetPropertyInfo + 56
28 com.apple.ecore 0x0261629c CAudioUnitRegistry::InitIOScope(ComponentInstanceRecord*, unsigned long, unsigned long, unsigned long, double, CAudioUnitRegistry::SScopeInfo&) + 112
29 com.apple.logic.pro 0x004b14e0 0x1000 + 4916448
30 com.apple.logic.pro 0x00109320 0x1000 + 1082144
31 com.apple.logic.pro 0x000c06a4 0x1000 + 784036
32 com.apple.logic.pro 0x0002ee34 0x1000 + 187956
33 com.apple.logic.pro 0x0002f034 0x1000 + 188468
34 com.apple.logic.pro 0x00030ba8 0x1000 + 195496
35 com.apple.logic.pro 0x0003116c 0x1000 + 196972
36 com.apple.logic.pro 0x0002678c 0x1000 + 153484
37 com.apple.logic.pro 0x00036874 0x1000 + 219252
38 com.apple.logic.pro 0x0032fc00 0x1000 + 3337216
39 com.apple.logic.pro 0x000113a4 0x1000 + 66468
40 com.apple.logic.pro 0x001e6e18 0x1000 + 1990168
41 com.apple.logic.pro 0x001eecb0 0x1000 + 2022576
42 com.apple.logic.pro 0x001eed44 0x1000 + 2022724
43 com.apple.logic.pro 0x001e3058 0x1000 + 1974360
44 com.apple.logic.pro 0x001e3194 0x1000 + 1974676
45 com.apple.AE 0x914f2960 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned long, unsigned char*) + 208
46 com.apple.AE 0x914f27fc dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 44
47 com.apple.AE 0x914f2654 aeProcessAppleEvent + 284
48 com.apple.HIToolbox 0x931db0e0 AEProcessAppleEvent + 60
49 com.apple.HIToolbox 0x9321ed24 ProcessHighLevelEvent + 140
50 com.apple.HIToolbox 0x9321ec7c StandardApplicationEventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 328
51 com.apple.HIToolbox 0x931d7794 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 692
52 com.apple.HIToolbox 0x931d6eec SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372
53 com.apple.HIToolbox 0x931d6d68 SendEventToEventTargetWithOptions + 40
54 com.apple.HIToolbox 0x931de0c8 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 704
55 com.apple.HIToolbox 0x931d79e4 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1284
56 com.apple.HIToolbox 0x931d6eec SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372
57 com.apple.HIToolbox 0x931ddc8c SendEventToEventTarget + 40
58 com.apple.HIToolbox 0x9321e9a0 ToolboxEventDispatcher + 92
59 com.apple.HIToolbox 0x9321e92c HLTBEventDispatcher + 16
60 com.apple.HIToolbox 0x9321cee4 RunApplicationEventLoop + 148
61 com.apple.logic.pro 0x001e99a4 0x1000 + 2001316
62 com.apple.logic.pro 0x0000bcd4 0x1000 + 44244
63 com.apple.logic.pro 0x00003584 0x1000 + 9604
64 com.apple.logic.pro 0x0000342c 0x1000 + 9260
Similar situation with standalone version; but it loads about 14 instances before Max crashes.
Okay, so the mxj wasn’t responsible for the problem (I never really understood how it could be)… I had the disk buffer size argument in both sflist~ and sfplay~, which is apparently a mistake. I’m a little curious, though, about how one gets the extra outlets argument on sfplay~ without messing up the disk buffer size (since the extra outlet arg needs to follow the disk buffer size argument)?
Does a disk buffer size argument on an sflist~ automatically override any arguments in associated sfplay~ objects? If so, I’m guessing we could use an argument of "0" in sfplay~ (thus allowing us to specify the extra outlets), but still have the desired disk buffer size assigned by sflist~. Yes? No?
On Jun 11, 2006, at 1:26 PM, jbmaxwell wrote:
> Okay, so the mxj wasn’t responsible for the problem (I never really
> understood how it could be)… I had the disk buffer size argument
> in both sflist~ and sfplay~, which is apparently a mistake. I’m a
> little curious, though, about how one gets the extra outlets
> argument on sfplay~ without messing up the disk buffer size (since
> the extra outlet arg needs to follow the disk buffer size argument)?
> Does a disk buffer size argument on an sflist~ automatically
> override any arguments in associated sfplay~ objects? If so, I’m
> guessing we could use an argument of "0" in sfplay~ (thus allowing
> us to specify the extra outlets), but still have the desired disk
> buffer size assigned by sflist~. Yes? No?
FWIW, If you have a disk buffer argument, they must be the same for
both sfplay~ and sflist~. If this is the case, it should work fine.
I had thought this was in the sflist~ help file (pretty sure it was
at some point), but it looks like it was lost somewhere along the
way. Will add.
Well, that seems the intuitive answer, and this is what I had originally done. But I was able to get more instances loaded by removing the argument from the sfplay~s, while leaving it in the sflist~. Dunno.
Anyway, I’m now able to get about 24 instances of my patch to open before Max quits. I’ll set the sfplay~s back to match the disk buffer size of sflist~ and keep messing around…
hmmm… if I knock down the disk buffer size my patch will load up to 32 instances. But why would this be???
[ EDIT — I’ve got 4 GB ram… and Max only shows 80 MB used in top ]
Sounds like you’re running out of memory. An example or better
description would help us comment further (keep in mind each instance
of sfplay~ has an internal buffer of 8x the disk buffer size and that
each cue loads either 1x or 2x (bidirectional) the disk buffer size).
Well, it certainly does seem that way, but I don’t really understand how that’s possible. As I said, the total memory listed for Max in top is only around 80-90 MB when Max quits. Now I suppose I may be getting an innaccurate reading from top, but it’s strange to me. Also, I was able to load up a bogus abstraction with the same general parameters, in terms of number of sfplay~s, sflist~s and disk buffer size settings. I’ve kind of given up for the moment; just bumped the disk buffer down until I could load as many instances as I needed. As long as performance seems okay, I’ll leave it as is.
Forums > Java