Originally Posted by MarioD
Originally Posted by musocity
I see all these issues and missing features also but this is a massive leap to have the Tracks view and Riff Edit they will be adding all the other things to it and polishing it up, they just ran out of time that's all.

That is the main problem with timelines. Instead pushing out a product that isn't finished why not wait until it is polished a bit more:
Though the problem with that is the high risk of the project just running on and on.

One of the hardest parts of software development is ensuring that all realistic .... indeed preferable all feasible ... modes of use are tested and proven. In practice, for much software, to achieve that is likely impossible. With the best will in the World, there are so many user-paths through BIAB, never mind execution and data paths, that the permutations for possible errors will be huge.

The trick (miracle, perhaps?) is to attempt enough that there is sufficient time to give things a good test and polish, without either over-running or under-demanding so people get too lassaiz-faire. PGM's business model is predicated on releasing new features in time for Christmas. A new version that does little more than last year's release, but works more reliably and robustly, doesn't really appear to fit that business model.


Hmmm ... the following reads like an elevator pitch for a job, but I'm definitely not looking for a job.

The types of software I design(ed) were quite different to BIAB, so I'm very wary of making comparisons. Doing so could be unfair on either PGM or on myself. Mine was mostly embedded real-time, PGM's is a quite different environment, though still pretty much real-time. When designing, whether at the outset or later when making significant changes, my main initial focus would be to get the data right for the application. I would often spend many hours making sure that it made proper sense, would support the planned behaviour and covered all the planned/expected options and also those that seem likely to appear in the near to medium future. It would include placeholders for things yet to be. The other thing I do is try to compartmentalise data and its associated behaviours. I actually learned that well, rather by fluke, as systems on which worked and later on which I did the main concept, hardware and software architecture, used distributed processors such that each module received combined action and data messages, and was compelled to handle everything locally. In reality this was a kind of "object oriented" environment, even though the term was still a bit esoteric, C++ was still being thought about and Java still a couple of decades away. That compartmentalisation has informed much of my work ever since. If I want data manipulated, then I send a message to the appropriate manipulator saying which data and what manipulation. That principle can also fit nicely with multiple CPU cores.

Jazz relative beginner, starting at a much older age than was helpful.
AVL:MXE Linux; Windows 11
BIAB2026 Audiophile, a bunch of other software.
Kawai MP6, Ui24R, Focusrite Saffire Pro40 and Scarletts
.