Split journal ID range between new and loaded elements

[jasp00]

Sometimes when loading projects like Greippi - Krem Kaakkuja (Second Flight Remix).mmpz, there are ID collisions and messages like JO-ID %d already in use by %s!. This may affect automation. To solve this, the range of IDs for new elements is different than for loaded ones. Another improvement is the optimization of assigning a random ID.

[DomClark]

Apologies for commenting on this over two years later, but it looks to me like there might still be the potential here for ID collisions. Say a control with ID EO_ID_MSB | 0xf00 is automated, then it will be saved with ID 0xf00. Now, when the project is reloaded, it is possible for another control to be given ID EO_ID_MSB | 0xf00, which is now free, and if that were automated, an ID collision would occur when saving the file. The chances of this depend on the number of controls already automated, but EO_ID_MSB is 2^23 so they will tend to lie around 1 in a million. This sounds unlikely, but we have millions of users, so it's not unreasonable to think someone will encounter this. Is this an issue or am I reading the code wrong?

[PhysSong]

That's why I'm trying to decouple automation from journaling. Journal ID should be unique in an instance of LMMS, while automation doesn't need to be.