[Jim Reid]

Heard:

"Current beta version of Leopard has a serious problem that prevents it
from working at all with the multi-platform library used internally in some
programs!"

Any news/truth to this, or just rumor?

Best, Jim

[chucker]

"the multi-platform library used internally in some programs"

Which is…?

[Jim Reid]

Hauptwerk, a virtual pipe organ emulation program. See:

http://www.crumhorn-labs.com/

Jim

[Kickaha]

Sorry, still not giving us any information... starting to smell like spam...

What is being asked is:

What library, used internally by some programs, is unusable in Leopard, and why?

Not what programs use it. That's not useful.

[Jim Reid]

Well, that is all the info I have about this. And, I am not sure I know what the meaning is of "multi-platform library" .

Probably best to just drop this topic.

[chucker]

So, what is your source?

[Jim Reid]

Who was my source? The author of Hauptwerk, Martin Dyde.
He has Hauptwerk operating beautifully using the 32-bit Apple MacTiger OS.

But, many organ sample sets run much larger than only 4 GB of
RAM needs. Thus a 64-bit operating system is needed. BTW,
large HW organs operate wonderfully using the XP-64 bit
operating system. He plans to "port" HW to Leopard just as
soon as he can, but reply's to me about the problem mentioned
here as needing to be corrected before he can upgrade HW
to the 64-bit Leopard system, with which we could use
8, 10 or even larger amounts of RAM for organ .wav sample
files.

I want to use Leopard on my Mac Pro asap, now loaded with 16GB of RAM.

However, now I am limited to only 4GB using
Tiger 10.4.9 . I am using MOTU sound equipment; it does not
get along all that well with XP-64, thus my great interest in
the use of Leopard.

I know, very specialized use, but.....

[julesstoop]

Couldn't he port the software to Xcode/obj-C?

[Jim Reid]

"Couldn't he port the software to Xcode/obj-C?"

I have no idea, I am only a user, not a programmer.

I'll suggest it to him if that really would do the trick.

Jim

[Enki]

Why is he trying to load an entire file that size? Tiling exceptionally large audio and video files is the standard way to do business. Not only does that let you use audio or video streams larger than the available memory, but it is far better for I/O responsiveness. It is a very naive thing to want to load the whole damn thing at once.

That says nothing of the bug issue real or imagined, but there is a better way that avoids that altogether.

[Jim Reid]

Perhaps because of the needed rapid access to the data;
to any bit of data in a .wav file.

A pipe organ can play hundreds, yes even a few thousand
pipes at one moment! Hauptwerk loaded into my Mac Pro
can reach, in any one instant up to a polyphony (simultaneous
pipe tone activation) of 6000 pipes with every nuance of the
pipe speech as caused by wind variations, pipe reaction to
deltas in temperature, etc. A very complex problem. And the entire harmony/chord structure can change in only a few milliseconds in staccato; interwoven in a fuge, etc.

What is the access time to audio data which is "tiled" ( I
have no idea exactly what tiling means.....).

Jim

[drewprops]

Holy orgasma!!
Do you have any audio samples online?? This sounds cool!

[Anthem]

I love pipe organs. They're awesome.

A digital one sounds really amazing.

[Jim Reid]

Yes, but please, I always get quite nervous (with stage
fright I guess) when the recorder is operating! Anyway,
this page has several theatre organ style samples of my
"duffer" level playing on a couple of excellent theatre organ
pipe sample sets. You can read all about them via the link
on above to the Hauptwerk pages.

Anyhow, here I am on Hauptwerk on a sample set called the
Milan 3/31 (three manual, 31 ranks of pipe sets) "Masterworks
Wurlitzer", and a Keymedia 3/27 using samples from a few different TPO installations:

http://www.leochristopherson.com/Jim...eid_page_1.htm

This is a page hosted by another fellow HW user/player. He was
kind and posted a number of my tunes and a too many words I
wrote about the music. There are many, many more samples
of Hauptwerk virtual pipe organs of all sorts: European, American Classic, etc. on the Hauptwerk web site, look under
the various Third Party Sample Set suppliers for a lot of
recorded demo tracks, all in .mp3 format, as are mine as linked
above.

Enjoy, I hope,

Jim

[Kraetos]

RE: The thread title.

Mail hide at startup?

[Jim Reid]

Yes, a few attempts to play to a recorder here:

http://www.leochristopherson.com/Jim...eid_page_1.htm

Amateurish sounding, as I am just learning to play theatre organ
style. Should'a stayed with Bach and Buxtehude maybe!

Jim

[rampancy]

Originally Posted by Kraetos RE: The thread title. Mail hide at startup?

I was going to chime in with "how about getting Mail and iChat to hide on startup?" but I just knew that if I'd say that, the death threads and letter bombs would start pouring in.

[Bryson]

Yes, they're going to definitely delay a major OS release to facilitate the use of Pipe-Organ simulators.

[chucker]

Well as far as I can tell, he's saying that there's problems with the 64-bit libraries (Carbon? Cocoa?). In that case, though, the original quote would be misleading, since Tiger has no such support at all.

[rasmits]

Originally Posted by rampancy I was going to chime in with "how about getting Mail and iChat to hide on startup?" but I just knew that if I'd say that, the death threads and letter bombs would start pouring in.

Why do you say that?

Every time I've ever mentioned this horrific, nasty bug I've seen nothing but support for the issue. I can't imagine why anyone would disagree that Mail and iChat should hide at startup when asked to do so.

[dfiler]

Originally Posted by rasmits Why do you say that? Every time I've ever mentioned this horrific, nasty bug I've seen nothing but support for the issue. I can't imagine why anyone would disagree that Mail and iChat should hide at startup when asked to do so.

The bug is incredibly minor and all the petty bitching gets annoying. It certainly isn't productive or even funny.

Now lets try to keep this thread on track.

I too would be interested in knowing if the bug report is real along with what exactly it involves. It wouldn't be surprising if 64bit support is flaky at first. Compared to other functionality, it affects a relatively small percentage of the user base and might not be high on the "before release" priority list.

On the other hand, it wouldn't be surprising to find out that the "multi-platform library" is a 3rd party library... or some other random but key detail.

[bassplayinMacFiend]

Yea, somehow I don't think Apple officially supports any "multi-platform library". I couldn't imagine Apple letting Cocoa 64 or what have you ship in an unusable state since all PPC G5 and Intel C2D computers will be running 64 bit code.

[chucker]

Originally Posted by bassplayinMacFiend Yea, somehow I don't think Apple officially supports any "multi-platform library".

Well, unless you count, say, Java. But the Java-Cocoa bridge is deprecated, and I doubt Java itself (through Carbon?) will initially have 64-bit support either. At least not that I recall.

[Kickaha]

Multi-platform -> 3rd party library. Pretty much by definition.

64-bit linking is quite different than 32-bit linking. It wouldn't surprise me in the least bit if a 3rd party lib, that links fine under 32-bits, has issues when linked under 64.

It's called porting the library.

[chucker]

Originally Posted by Kickaha It's called porting the library.

Oh please. It's called not using it to begin with. Sheesh.

[Moogs]

Originally Posted by Bryson Yes, they're going to definitely delay a major OS release to facilitate the use of Pipe-Organ simulators.

QFT

[Kickaha]

Originally Posted by chucker Oh please. It's called not using it to begin with. Sheesh.

I keeeeeeeeeeel you.

[dfiler]

Originally Posted by Kickaha Multi-platform -> 3rd party library. Pretty much by definition.

Not by everyone's definition. In my opinion, a significant portion of OS X is pretty much a "multi-platform library".

It really comes down to how one perceives the rolls various parties play (and have played) in brining software to market. The various bits and pieces that comprise OS X have long, complicated, and varied legacies.

Since even seasoned programmers can't come to a consensus on defining such a gray line, it is hard to know what Martin Dyde meant without further clarification.

[Enki]

Originally Posted by Jim Reid Perhaps because of the needed rapid access to the data; to any bit of data in a .wav file. A pipe organ can play hundreds, yes even a few thousand pipes at one moment! Hauptwerk loaded into my Mac Pro can reach, in any one instant up to a polyphony (simultaneous pipe tone activation) of 6000 pipes with every nuance of the pipe speech as caused by wind variations, pipe reaction to deltas in temperature, etc. A very complex problem. And the entire harmony/chord structure can change in only a few milliseconds in staccato; interwoven in a fuge, etc. What is the access time to audio data which is "tiled" ( I have no idea exactly what tiling means.....). Jim

A tile is just a portion of his overall sound file, think of tiles on a floor where the whole floor is his gigantic file. Tiles can be made in arbitrary sizes/content qualities.

Depending on what he needs he would have mixed issues with multiple files (tiles). This really shouldn't be a problem though since there is a distinct difference in needing a file during music creation and needing a sound component during playback.

During playback the concept is simple, you already know what you need so you only need to load that data. This is much faster using tiled schemes since file sizes are smaller meaning less search or indexing required and VASTLY shorter load times, and you can also fit into smaller memory footprints without loss of fidelity. Essentially you only load those sounds you need and those closely related sounds that reside in the required sounds tiles. You can leave all the unsused stuff on the HD and not muck about with it.

During creation you could run into some delay issues if the tile loading scheme doesn't pre-load the particular tiles you want. But since it is essentially an "offline" or at least non-performance situation your price is a wait of a few tenths of a second to get those tiles loaded and continue creating. I'm sure there is quite a bit of savings that can be made since there will be mutually exclusive situations in the complexities you mention above such as pipes in close proximity not having DRASTICALLY different environmental conditions. This does require careful though on how to organize and index the data. But that thought can pay off significantly in actual performence and resource requirements.

[Kickaha]

Originally Posted by dfiler Not by everyone's definition. In my opinion, a significant portion of OS X is pretty much a "multi-platform library".

The core BSD systems? Sure. Some of them have had their APIs preserved, and work on other platforms as well.

Anything that is going to be used for audio processing, however, is going to be CoreAudio/QuickTime (not cross-platform, unless you count QT-Win), or not-from-Apple. ie, 3rd party. Really, think about - it if he's running on XP/64, then the library he's using is either QT, or something else from another source. Since he's running on XP/64 *now*, I'm pretty sure it's not QT.

Since even seasoned programmers can't come to a consensus on defining such a gray line, it is hard to know what Martin Dyde meant without further clarification.

However, we can use logic to tease it out.