@kasper Thanks for the report -- I've fixed this for the next version.
@kjg It is quite difficult to support OS 10.4 now. The version of Xcode I have installed from Apple doesn't even have the option of installing support for 10.4 anymore. I guess this is Apple's way of dragging us along kicking and screaming.
too bad that there's not win version.
the multiplatform nature of max/msp is still neglected by a lot of third party objects developers.
i understand their reasons very good.
but often i feel like a "paria" windows xp user :(
'well, at least you guys have the excuse of being the 'new kids on the block': there are some users who have been owners of Max since before Msp, first year adopters of the original TapTools, fully paid, who are now dropped from it's further development because of Apple's great ability to re-invent itself. I lost my favorite DAW (Vision) when Apple first went to (the superior) OS X...now I lose TapTools because of Apple's lovely fickleness.
i also wanted to contribute to Jamoma.
No chance now until a raise magically appears during the worst recession since the 30's or i win the lottery. P.S. "MacBusinessSystems" here in my hometown will sell a used G5 to you for < 300$.
As the saying goes, there are lots of ways to skin a cat. Particularly in cases like this, you have lots of options as you have more resources available to you. Cycling has a lot more resources available to it than Electrotap or 74Objects have available.
In the case of Tap.Tools, those resources are extremely limited in the best of times. And, as Charlie points out, these are not the best of times.
In the case of Jamoma, it relies on volunteers -- so the hard work of (backward) compatibility falls to whoever is interested in doing it for free. If anyone would like to volunteer, please do! You are certainly welcome in our family!
hmm. Jamoma. ok. pulled from github, but the ruby build fails looking for a file that probably exists for intel platform pulls: ./supports/jamomalib
I can run "Xcode"/gcc since it was "AppBuilder" (NeXTStep)?... or is the dsp code itself hand coded intel SSE or whatever these days?
Any ideas, Tim?
PS Tim, I admire you for working so hard for new music, when as I know too well, the demand for coders still goes on for standards industries like insurance/banking, and they're not going anywhere. We Hope. I wish you the kind of success my old colleagues at UI CERL have had with their commercial ventures (Kyma, Continuum).
after the ruby update step (which completed), I started the compile, which immediately dies on the dependency "/supports/jamomalib" (./supports/jamomalib in Builds. it is not there.)
Unless the update failed (i did little but scan the verbose output, but saw no obvious failures), the issue would (seem) to be that I am on an unsupported architecture, :), which I knew, but was hoping to work through any porting issue; this dependency is a bit much: without source to solve this dependency... I suspect that the update failed to find the jamomalib for my architecture, PPC, because it does not exist, so I do not have it. I asked if this lib was *by nature* intel only... but have not heard back about that.
Keenly interested, but I am 'unsupported':
I am a +50yo programmer/composer-(PhD in comp UCSB)/user of Max for 20 yrs...but until i get to buy anything other than my family's life-support, Jamoma will have to wait... unless the missing dsplib is actually in some nice compilable language, rather than the swift and ubiquitous intel assembler... :-), he said, not having much hope.
cfb aka j2k