About native linux version: the big problem in my opinion is that
- we cannot offer support because there are way too many different distributions

Just as someone replied to you already: you don't have to create a package for every distribution. Just one dynamically and/or statically linked „all in /opt/pianoteq” is enough.

It's not a mess, it's a choice. Pick one layer that suits you. (But for audio production (for users) I think JACK would be the best choice.)

I'd buy Linux version long ago, but it isn't available. Under wine it doesn't work well (big latencies, unstable, weird audio clicks, etc).

A native Linux version would be great if it improves performance.  Especially with Pianoteq 3 and the new "recording setting" with 5 microphones, Pianoteq can take 50-60% of the CPU time on my 1.5ghz dual core!

But it is perfectly, fully functional except for the registration process, which crashes the program still (but you are fully registered upon restart

EvilDragon wrote:

ldeza wrote:

I have noticed that when you play a midi file, it will not stop automatically when the file ends, seems to be a little bug?

Nom this is the same behavior as in V2.

Really?

Well, if I remember right it stopped when the midi file ended. Now if you load a new one it will start automatically because the play button remains green

Regards

That's exactly what was happening in my V2.3. I guess it's normal.

ldeza wrote:

I have noticed that when you play a midi file, it will not stop automatically when the file ends, seems to be a little bug?

Nom this is the same behavior as in V2.

Really?

Well, if I remember right it stopped when the midi file ended. Now if you load a new one it will start automatically because the play button remains green

Regards

I have noticed that when you play a midi file, it will not stop automatically when the file ends, seems to be a little bug?

Nom this is the same behavior as in V2.

The .dll loads fine too in the beta version of cantabile 2 x64

I have noticed that when you play a midi file, it will not stop automatically when the file ends, seems to be a little bug?

Noticed too that the real time polyphony information is not displayed anymore in the main screen, now it is in the Perf tab of the options, a little bit hidden I guess.

Of course nothing of this is related with the x64 version, but it is just the version I tried

Best regards

About native linux version: the big problem in my opinion is that
- we cannot offer support because there are way too many different distributions
- a linux standalone version need to deal with the audio layer, and audio on linux is a bit of a mess (oss, alsa, jack, now pulseaudio..)

I disagree on both points.
- It is not necessary to support a distribution. Just make a decent tar.bz. If you like, you can create a package for a dist or ask them to do so.
- Just pick a audio layer (alsa or jack, OSS is dead), or make it a plugin. For your app I would go for jack.

Please create a linux version.

Vista 64 makes me nauseous.

Then wait for Windows 7

Yes, but you still have to transfer the working data FROM hard disk to RAM, and this is purely hard disk speed dependant. So no improvements there.

The only improvement is when using large sample libraries, you can load them whole in the large amount of RAM you will be able to have. BUT, it still takes time to load the samples from the hard drive! And it's still quite slow today. But, solid state drives are soon to be mainstream and this will be remedied.

Also, 64-bit apps can ONLY be slower if they weren't ORIGINALLY written for 64-bit system. This happens when wrapping 32-bit applications to run on 64-bit system - conversions take time.

Is there actually an appreciable performance improvement with the 64bit vs the 32bit?

As I understand it no, in fact 64bit apps can be slightly slower. What makes 64bit better is that it can address more RAM, I believe 32bit Windows is Limited to 2 gb or 3 gb if you enable the 3 gig switch. 64bit systems of Windows and Macintosh OSX are limited to 4 gb with 32bit apps.

With 64 bit apps on 64bit systems there is effectively no limit to the amount of RAM that an app can access, more than you can fit in any current computer anyway. So if a 32 bit app is writing to hard drive a lot it will be slower than a 64 bit app that can write all data into RAM. This is because RAM is much faster than any existing hard drive.

Vista 64 makes me nauseous.

About native linux version: the big problem in my opinion is that
- we cannot offer support because there are way too many different distributions
- a linux standalone version need to deal with the audio layer, and audio on linux is a bit of a mess (oss, alsa, jack, now pulseaudio..)

Hmm, I see, still too many problems with Linux then.
Thanks your quick reply.

No 64-bit mac will come later, not before Snow Leopard (Mac OS 10.6) is released, I think. For now, the only 64-bit host on mac is, as far as I know, aulab.

Fair enough, thanks for the info!

About native linux version: the big problem in my opinion is that
- we cannot offer support because there are way too many different distributions
- a linux standalone version need to deal with the audio layer, and audio on linux is a bit of a mess (oss, alsa, jack, now pulseaudio..)