Future computers, processors, and software must have such efficiency and low power consumption that they can be powered using only green, clean energy like sun, water, and wind.

We need Intelligence and long-term vision before stupid raw processing power.

IMO simplification is not only a compromise, it can be a challenge, and an act of intelligence, creativity, and vison. 

Now I'm switching off my computer ( I confess: I have one too ) , and go play my unplugged grand piano again :-)

Well if I had the choice, a 10GHz core i7 solo would put a larger smile on my face than a 2.8GHz core i7 quad, as multi-threaded coding is quite tricky especially in a real-time context.

Managing the allocation of processors in a parallel computer have always been a nightmare for hardware designers and software developers ! Despite thousands of studies, papers, theses ad developments... since the '70s, this problem has never been completely solved - I mean on a general basis!

One thing is sure, however : a polyphonic sound generator is naturally appropriate to parallelism. But software resources in present OS of personal computers might not be smart enough to manage it efficently in a real-time context.

Alain

The things I would like to see would probably just reduce the polyphony a little:

--The sound of a worn (beer soaked?) action--the creaky, springy sound on old pianos as the hammer moves up to strike the strings.
--The ability to tune each unison string separately.
--The multiplication and decay of some freqs that creates the body resonance. I imagine that a fully accurate rendering would tax the cpu. It might require a set of parameters like the soundboard resonance. But I can imagine a simplified version that simply emphasized and slowed the decay of some freqs.   
--the ability to add noise. Looking at recordings of piano notes in spectrum analysis programs, I often see a lot of freqs between the partials, particularly in the lower end of the spectrum. PTeq has these, too. Would be nice, however, to have a separate spectrum Note edit pane for controlling what was added. This might be part of what's needed for body resonance.

And some things that wouldn't affect the polyphony or cpu load:
--More control over the timbre of the hammer\keybed strike.
--the ability to repitch each partial.
--the ability to change the string diameter, which would go a long way towards letting us repitch each partial.

Well if I had the choice, a 10GHz core i7 solo would put a larger smile on my face than a 2.8GHz core i7 quad, as multi-threaded coding is quite tricky especially in a real-time context.

Thank you, Julien!  That's what I was thinking you would say.  Core clock speed still trumps a plethora (gaggle?  flock?  herd?) of cores.

Does a difference exist between coding for "virtual" cores (i.e., "hyperthreading") and real cores?

In the same way I think the CPU limitation forces programes and mathematician to find alternative, be creative, find short cuts etc.  This contributes somehow to refine technologies.

There are some interesting comments about modeling on PianoWorld.  The following is a comment and a reply:

Comment:

I'm skeptical. I don't think that computing is the problem. Rather, I suspect the modeling is not up to the task.  To be fair, that's just speculation. But no one here seems to know anything specific about modeling. It's hard to draw conclusions without first having facts to base them on.

Reply:

On Sylfid (sylfid.com), we have been trying to model just the strings (not the soundboard). Computational power is indeed the big problem. Even on a quad-core PC, we need to use a simplified version of strings in order to get a real-time simulation.

Exactly my point;
Which "simplifications" will be coded for execution in real time as processors become faster (and more numerous) ?

Sound boards aren't "Simple", look up Vigdorchik tap tones some time to see what violin makers worry about in the physical realm (-:
I think it can be modeled very well, the model just can't (yet) be run fast enough for anything resembling a live performance.

Comment:

I'm skeptical. I don't think that computing is the problem. Rather, I suspect the modeling is not up to the task.  To be fair, that's just speculation. But no one here seems to know anything specific about modeling. It's hard to draw conclusions without first having facts to base them on.

Reply:

On Sylfid (sylfid.com), we have been trying to model just the strings (not the soundboard). Computational power is indeed the big problem. Even on a quad-core PC, we need to use a simplified version of strings in order to get a real-time simulation.

The sound tone quality of actual models do not change with higher CPU.

This is what COULD change in v4, that is, the scalable model.

Can you tell us if the Pianoteq engine benefits from faster speeds or additional cores?  Which would put a bigger smile on your face, as a programmer?

Well if I had the choice, a 10GHz core i7 solo would put a larger smile on my face than a 2.8GHz core i7 quad, as multi-threaded coding is quite tricky especially in a real-time context.

You just get more polyphony, can use and feel safer that will not get cracks with high pollyphony moments.

Julien, are you out there?  Can you tell us if the Pianoteq engine benefits from faster speeds or additional cores?  Which would put a bigger smile on your face, as a programmer?

It benefits from both, but I'd say multicores are the way to solve complex calculations.

EvilDragon wrote:

The future of CPUs is NOT in the frequency! It's in the multicores!

Which then begs the question.  Like computer animation, video and image processing, do the Pianoteq computations lend themselves well to using multiple cores?

(this maybe answered in a FAQ already, but my lunch is over and I have to get back to work)  ;-)

My guess is "Yes".

That is based partly on my perception that Philippe et al are anticipating the technology curve(s) and have some design ahead of it and waiting.
Also based on my guesses as to what the model actually IS and how it has been implemented... don't put much faith in this part though (-:

Hmmm, I s'pose I could monitor my dual core CPU usage to see if PTQ hammers both cores approx the same.
In a LOT of apps it hardly gets around to using the second one, but that might be more about windoze and 32 bit legacy issues than anything else.

Yes, I worded that bit about 5GHz machines poorly, but I no longer think in MIPs and was in a hurry.
I probably had "about twice today's 2.x GHz dual core machines" in my mind.

The future of CPUs is NOT in the frequency! It's in the multicores!

Well, to be honest, from what I've read, I have the impression that the answer isn't so clear-cut.  More cores are obviously a good thing, but you have to take into consideration "overhead" -- i.e., how the system routes the activities (efficiently) to those cores.  If I'm not mistaken, Pianoteq benefits greatly from both features, but the speed probably takes precedence...?

Julien, are you out there?  Can you tell us if the Pianoteq engine benefits from faster speeds or additional cores?  Which would put a bigger smile on your face, as a programmer?

The future of CPUs is NOT in the frequency! It's in the multicores!

Which then begs the question.  Like computer animation, video and image processing, do the Pianoteq computations lend themselves well to using multiple cores?

(this maybe answered in a FAQ already, but my lunch is over and I have to get back to work)  ;-)