DunedinDragon
i feel compelled to comment ..
(as also a seasoned retired puter bloke like your good self)..
on some of your comments.

application developers, as well you know,
are often limited by the underlying hardware technology at any point in time as well
as the development tools available and limitations of the OS itself.
so i'm gonna turn your comments around.
its not exactly easy developing music apps in the win environment imho.
ive looked at the win audio n midi programmer api's for example because once
years back i was getting frustrated with music software not doing what i wanted.
and i was at one point very seriously thinking bout putting a team together
of seasoned blokes to build a bonzo music app.
but when i looked at the those api's frankly i felt they were overly
complex and not easy to use.
which is why i laud the pg developers that they could bring to market and build a large
user base. initially around biab and then follow on products.
i'm sure Mr Gannon and team had many hair pulling moments n hair going grey dealing
with various technical issues.
its intersting to note in many respects biab is unique in the market.
i bet because seasoned developers would realise the technical challenges involved.

then i looked at the underlying OS.
its purpose originally was to be a general purpose OS..correct ??
ideally for music apps a proper real time OS imho should be de rigeur.
but that is not the case , so programmers of various daw software have had to
resort to various "tricks".
for example to create the "illusion" of things happening in real time playback
for example..
for the end user...
reading time slices for mixing into main memory before they are needed.
ie "look ahead" techniques.
seek time and limitations of disk drive technology
also play their part, as well as memory speed and various other factors.
for example one problem with high level api's is time to execute at the kernel level in the OS
itself. wouldnt you agree ??

in summary with all due respect you cant lay all the blame with
application developers like pg.
they are limited by forces outside their control often.
as well you know mate. a developer can only do so much and is often faced with
changeing OS versions, changeing api's, changes in underlying pc hardware architecture,
etc etc. this constant change of underlying platform plus trying
to keep a diverse user base happy represents a major challenge to even the
most seasoned "been round the block many times" developer.

now lets turn to the gui itself.
on this one imho pg are on a hiding to nothing imho.
ive used some of the flashy gui's in music daw software n fancy shmancy stuff.
as well you know, there is overhead with every bit of source code.
more features..result in more source code.
and frankly some of the new fancy gui's can be problematic on
earlier clunky pc's with old OS versions.
what i perceive is good old pg have tried to make it so the products will
not only work on the latest uber power pc's but also older pc's because
not everyone can afford a new i7 with all the bells n whistles.
the other problem is if pg redesign the gui..lots of long time users
might not like it cos they are used to it.
ah ah !! i hear some people say. so offer an option..new style and old style.
heck lets even let the user configure the gui anyway their hearts desire.
why not go the whole hog and include a gui generator just like one might find in
a programmers compiler.
BUT THAT POSES ANOTHER PROBLEM.
more source code and more bloat being but one problem.
and more maintenance of source code.
as i said pg are on a hiding to nothing.
this is one of the problems one encounters as a developer trying to keep
as many people in the world happy as possible.
ive been there done that with user bases myself many times in the past.
and the conclusion i came up with is ..
you can never keep everyone happy.

dont even get me started on programming on the pc mate, and the fact if one uses
cetain C++ compilers one has to deal with loverly big run times.
why werent the compilers designed to create stand alone executables ??
instead of needing big run times ??
(eg like purebasic.com with in line assembler).
someone can correct me if i'm wrong but its my understanding pg used
borland compilers in the past because with those no big run time
was needed. a logical choice imho at the time.

in summary your post is critical of certain pg aspects..
but in many respects dont you think many of those aspects
are a result of design and programmer tool decisions made way back in the development of win
itself ?? some people like the mac os. me i'm this way and that.
i like small elegant real time OS's like menuetos.org.
(give it a gander sometime.but no music software for it)
and feel that music software developers lives could have been made
a whole lot easier over the years with a proper elegant small OS
dedicated to the music creation vertical market with easy to use
development tools and of course most importantly a extremely fast low latency os kernel
relating to audio applications .

i just find it amusing your critiqueing a product that runs on the environment that you
once worked in. an environment itself that some might say is not perfect.
and which created lots of the tools devs work with on a daily basis.


just my 2 cents n wishing you only the best.

retired puter engr....powertracks on amd......NICE !
"what is the black art of audio engineering ?"
my silly songs...motagator.com/bmanning
see my tips in the tips section.