BREAKING CHANGE: Labels are not persistent by default anymore.

[Christoph Hart]

From now on, the Labels will not have the saveInPreset flag enabled by default. The rationale behind this is to remove the necessity to deactivate it manually so you can enter a text right away.

However this means that if you haved used a label with the saveInPreset flag, you will have to explicitely activate it again - just load up the interface and change the property back to true, then resave (from then on it should pertain the saveInPreset value).

[Dan Korneff]

Is this for the ScriptNode branch?
Should we stop using the Develop and Master branches?

[d.healey]

@dustbro If you click on the "Branches" tab you can see when each one was last updated.

[Dan Korneff]

@d-healey said in BREAKING CHANGE: Labels are not persistent by default anymore.:

If you click on the "Branches" tab you can see when each one was last updated.

yeah, I saw that. I'm trying to stay current with everything that's going on here, but I can't tell if ScriptNode is a complete new program, and the other branches are being phased out?

[d.healey]

@dustbro Any branch that isn't master is unstable (and master can be unstable sometimes). If you want the most stable then go to the Releases tab and download the latest, that's what I'm currently using. If you want to play with new features then use a more recent branch. All branches come from the same root so unless Christoph totally clears a branch and starts from scratch none of them will be a completely new program. HISE node is a new feature in the existing HISE program.

[Christoph Hart]

So the branch policy is:

• master should be always compilable (I screw this up sometimes, but it shouldn't be the case) and should be used for compiling plugins that are shipped (eg. HEXERACT is always build from the master branch). Also any hotfix that is guaranteed to not cause side-effects but fix critical errors are directly applied here.
• development branch usually contains the latest state. Might compile on some platforms, might throw a few std::fabsf not found compile errors on Linux to prevent David from using it.
• any other branch is spawned off from the development branch and contains a new feature (currently scriptnode). As soon as this is ready, I merge it back to develop, and in regular intervals then to master if it's considered stable. The state of these feature branches are totally random - sometimes I just have to push an intermediate state when I switch systems.

This workflow is known as Git flow. The only problem is to stay consistent with it, and in certain situations it leads to inconsistency. Right now I branched the scriptnode branch from master (instead of develop), so develop is really useless right now.

TL, DR: Use master for a production ready codebase, scriptnode to check out stuff that was done in the last weeks. Forget about the development branch as long as scriptnode is active.

[Dan Korneff]

Thanks guys!

@Christoph-Hart said in BREAKING CHANGE: Labels are not persistent by default anymore.:

develop is really useless right now

Does the Master Branch contain the fix you did with overlapping midi notes? I thought that might only exist in develop... and if so, what's the best way to compare the branches so I can see what's different?

[Christoph Hart]

I merged develop into master on May, the 2nd. After this nothing serious was done there, so yes, the MIDI fix should be in master:

- fixed overlapping notes being ignored · christophhart/HISE@28cd62d

The open source framework for sample based instruments - - fixed overlapping notes being ignored · christophhart/HISE@28cd62d

GitHub (github.com)