Is it very difficult to make each bar 4?
Please design each bar so that 4 chords can be input directly.
I hope we don’t keep everyone waiting until 2025.

Well, we've been here before.

I support this, with two assumptions:

One, that this example is for a time signature of 4/4. I still hope that we might someday see more complex time signatures, but what is portrayed here is that one beat gets one box. It the time signature was 3/8, for example, we would have one box per eighth note andf three boxes per measure. If the time signature were 3/4, there would also be three boxes per measure etc.

Two, that subdivisions of each box are possible. That way, the microchords that are presently possible would still be possible.

Yes, another vote of support, along with the suggested necessities.

+1

I presume that back at the dawn of BIAB time, whoever did the initial design reckoned that 4/4 and 3/4 were enough and that it was unlikely anyone would want more than two chords per measure or would find the workarounds "too hard/clumsy/silly". It seems very much to me like that it was then baked-in. To add the extra chords per measure without breaking whatever "step to next chord" key(s) they were then using (I imagine it was "Enter" right from ther start), they instead chose to separate the existing chords from the new additional chords with a new and different separator. And that too stuck. If I'm right, then for the life of me I can't understand why they thought people couldn't or wouldn't adapt to a double-key to step twice. I do like the box-per-beat look.

Similarly I imagine that the 4/4 constraint was tied to compact use of data right at the start. Ditto the 255 or 256 measure limiit. What I struggle to comprehend is why on Earth they didn't address all of those things at the earliest opportunity, instead propogating the fails for decades. The longer one leaves these things before fixing them, the greater the pain. Those are 8-bit data constraints. We're no longer working on 8-bit computers.

I struggle to fully understand even why it appears so painful for them to change.
If it's really just a worry about compatibility to older versions, then offer a program-only upgrade amnesty to the version with the changes.
I really think it would make PGM's task easier, quicker and lower cost in the longer term to fix it.
And it should end a huge amount of user frustration.

You touch on some valuable points, Gordon. Yes, the longer it takes to have these worthwhile (necessary) functions incorporated, the more difficult it will likely be to lever them in.

255 bar limit, floating-point tempo's, alternative time signatures (5/4, 6/4, 7/8 etc) and more come to mind.

Gordon, I agree completely. We've had these discussions going way back two decades before you joined the forum. The '255 measure limit' is only the clearest example of an 8-bit constraint. I suspect most of us here will recall that in the days leading up to Y2K, we solved that by expanding the length of the date fields, but it's an indicator of how precious disk storage used to be to keep the length of a record short. **

The floating point (non-integer) tempos is a good example where the field in the record ** needs a change of type.

PG Music could create a utility that would be a one-time conversion of old song files to meet the new format, so backward compatibility could be assured. I think the one-beat per box concept also may have originated in recent years by Swingbabymix (I'm willing to give him credit unless someone can prove otherwise) but the assumption in that idea has always been that subdivisions within the beat would be possible, since the idea originated around the same time as microchords.

** for anyone not sure what these refer to, the hierarchy of data is simply this: bit, bye, field, record, file, database. Each is a collection of the prior one.

Thanks Trev, I'd forgotten floating-point tempos ... yes, same issue I think.

I agree that a one-time conversion utility is a good strategy for the future sounds like the cleanest approach, though I suspect PGM's concern would be with older copies of BIAB being unable to work with new songs. At present, I can send an SGU/MGU to someone with a much older BIAB and, apart from the likely style substitution, generally it will work. If the file format is changed significantly, that will no longer be true. That appears to be important for PGM and I commend them for it ... many, maybe most, companies would not do that.

There are several possible ways to deal with the compatibility issue and I'll start by ignoring the "tough, it''s changed now" option as contrary to PGM's philosophy. Two options that strike me as suitable are either/or:

• make a backwards-convertor from new format to old format and have it available as a free download (make a new product and give it away free ... not a great business case in itself)
• the "amnesty" ... a program-only upgrade to the BIAB with the new format for a peppercorn fee.

In practice, even the Pro upgrade from any pre-2022 version at $79 isn't punitive, but discounting harder once (e.g., keep the 2025 version only at, say, $20 for some years) would get rid of lots of backwards-compatibility planning, coding, testing, bug-fixing and the rest. I can't know PGM's internal concerns, but looking at is as a outsider with experience of similar issues, to me it sounds like, longer term, that would likely save time, money and probably staff frustration too.

The amnesty option might warrant a "sweetener" for the people who upgrade most years so may feel a bit robbed, or it could mark a start to a content-only pricing strategy for the future. Only PGM can decide what's really best for their business plan. I suspect that it's possible that getting these tired old issues out of the way for once and for all might actually be sweetener enough. Maybe a poll?

Many of us have stated that for just one release, we would prefer to see 50 'improved features', rather than the usual 50 'new features'. Those 'improved features' would handle the constraints of 255 bars, integer time signatures, complicated and sometimes confusing menu structures, and much more.

I personally think it would be a major selling attraction to users. Many users probably don't upgrade because they don't consider this or that new feature sufficiently useful. On the other hand, I am confident that significantly more users would upgrade if it fixed some of the existing shortcomings that they currently endure.

Unfortunately, we have never been able to convince the company to adopt this approach.

It might be harder to get users to "pay for fixes" rather than new features ?
I think Peter may of said it would be easier to add the chord entry on any beat in the Track view Chord Track same as Cubase, Studio One etc.. ?

The best place to start with real time signatures, 255+ bars, real tempo maps is with the JUCE Plugin when they move the generate code into it, get rid of all the old limiting factors, giving it a quantum leap.
I can generate up tracks in Reaper in any time signature and any number of bars.

I wonder how many people don't upgrade because of all the new bugs they know will appear with the new features.

When I tried BIAB again after a six year (IIRC) hiatus, it was at a time when there were a great many bugs and bug-fixes over almost the entire year. It was a painful time because I spent so long trying to fully identify bugs and make them repeatable for the developers.

I look at this years changes and that there have been quite a few bugs and fixes and I'm now reluctant to get involved. I upgraded my Audiophile edition and bought the add-ons, but in truth I've barely used BIAB since. So many old bugs are still there, so much clumsiness and arcaneness are still there, I still struggle to get some things to work as I think they should. As a consequence I've reverted to iRealPro for much of my practice and I've backed off from my thoughts that I might try producing music from BIAB.

They're gradually losing me.

+1
I think that's a good thing, users going through all this with Biab, it's a great learning tool of what not to do, what's not really needed...and take all of that and put it into the Plugin/Plugin Standalone to development into Biab Lite (no bloat), easy to learn, easy to use, EZBBvst, bring a younger audience to Biab to future proof it. Look how wonderful EZDrummer is, it stayed version 1 for ages, the BBPlugin is up to version 6 and still has issues as it's using old BBW4 in the background. Is 7 a lucky number ?
I know I'm the only one that keeps incessive nagging about this but I think other users need to see the light and get onboard as I don't know how the Delphi and 6mths Win then 6mths Mac will hold up going into the future ???? is there really a future for this 10-20 years from now ????

[quote=musocity
...............................................................
I know I'm the only one that keeps incessive nagging about this but I think other users need to see the light and get onboard................................. [/quote]

I have been calling for a complete rewrite for many years now. However every time I post that I get shot down. Its funny in that every other music software I have used has either had a complete rewrite, did real meaningful upgrades, or they went out of business. I have been using music software since the mid 1980s!

As far a what language that is way above my pay grade. I haven't programed anything other that Lotus 123 and Excel macros for many many years now.

+1
yes there has been a lot of shooting down, those users don't realize how they have held it back by trying to protect PG's feelings from getting hurt.

I know the post is about chord entry but at some point we need to look at the bigger picture.
I did post these before:

Consider the approach Microsoft took with its Office apps. When they added the new files formats (e.g., .docx and .xlsx), they provided backward compatibility at the file level with Save As .doc or .xls, with the warning that newer features that may (or may not) have been used in the current document or spreadsheet would be lost. At least the files could be opened by older versions of the software.

I also recall Save As options for specific older versions of a given app.

So...SGUX and MGUX?

Yes, I think you're right. My thinking for the external app was to get as much clutter out of BIAB as possible, but having to run an external app is an unwarranted extra task. Of course the process for saving could perhaps just call that external app.