clef-development — Developer List

[clef-development] Fwd: change in git --> Master now the main development branch

[Schumacher M. <mar...@mu...>]

Hey everybody,

I recently announced a "change in git" on this list, merging the 'stable' branch into 'master'. This change just happened, i.e. the "master" branch is from now on the main development branch. Branching/merges should be done from/into this branch. 'stable' will become the "release branch".

Best,
Marlon

Begin forwarded message:

> From: Schumacher Marlon <mar...@mu...>
> Subject: change in git
> Date: 30 December, 2012 18:00:14 EST
> To: cle...@li...
> 
> Hey there,
> 
> As you've probably noticed much of the recent developments have been pushed to the 'stable' branch, mostly since we've been working on CLEF in the context of different classes/projects at McGill. I'm planning to make a merge/change in git:
> 
> "Stable" will be merged into (i.e. *become*) the "master" branch. From then on, "master" is going to be the main development branch. "Stable" -which should be working at all times- is going to be used for builds/distributions, e.g. for teaching purposes and projects. Changes which are specific to projects, as well as development of certain experimental features should go into dedicated branches which can eventually be merged into "master". I will also make a "Les Gestes" branch from the current "stable" branch.
> 
> So if you still have developments going on you should push them to "stable" (unless you are already using a specific branch) before I do the merge.
> 
> Cheers and Happy 2013!
> Marlon

[clef-development] question about osc-lanes

[Schumacher M. <mar...@mu...>]

Hey,

Just some announcements to get (perhaps) some feedback. We implemented a number of osc-lanes (for automation) on the "osc-lane"-branch. There are currently 3 different ones (implementing different logics for user interaction):

1) clef.osc-lane.absolute.wgt

That's the original and most "classic" or "generic" version, similar to automation tracks found in DAWs. 
 -> function-values (i.e. points) aren't changed unless "edited" explicitly by the user)

• the event-duration changes the domain (i.e. what is displayed in the function)
• x-min and x-max have no immediate effect but set the boundaries for normalization
• y-min and y-max change the domain (the displayed range) and set values for normalization.

-> probably slowest to work with but most flexible.

2) clef.osc-lane.absolute-2.wgt

This is a similar version to absolute.wgt albeit with a few shortcuts to facilitate user-interaction.
 -> function-values (i.e. points) are auto-normalized by dragging x-min/max and y-min/max

• the event-duration changes the domain (i.e. what is displayed in the function)
• x-min and x-max normalize immediately
• y-min and y-max normalize and setdomain

-> faster to work with but less flexible as for the y values it is impossible to extend (increase the y-distance) between the points (since the y-min and y-max normalization also sets the domain the display is always 'maxed out'). I.e. one cannot individually set the displayed range and the range of points.

3) clef.osc-lane.relative.wgt

This is a version taking a few shortcuts to facilitate user-interaction.
  -> function-values get edited destructively by changing event-duration

• the event-duration sets the domain (i.e. auto-rescales the function)
• x-min and x-max have no immediate effect but set the boundaries for normalization
• y-min and y-max change the domain (the displayed range) and set values for normalization.

This distinction/implemented functionality doesn't seem to make quite sense to me yet. The 2 latter ones seem to be kind of hybrids (in terms of 'logics'), ideally there should be only 2 complementary ones: clef.osc-lane.absolute.wgt and clef.osc-lane.relative.wgt). I think the issue is that one cannot auto-rescale while at the same time being able to extend the domain (i.e. what is displayed). The latter one demands an extra control for 'normalize-y'. Perhaps then the clef.osc-lane.relative.wgt makes sense. But then again, it could also make sense to have the distinction between one that sets the display and doesn't change immediately (absolute), and another one the changes the values immediately.

PS You can have a look/compare them in /Library/Events/osc-lane/osc-lane-test.maxpat

Marlon

[clef-development] change in git

[Schumacher M. <mar...@mu...>]

Hey there,

As you've probably noticed much of the recent developments have been pushed to the 'stable' branch, mostly since we've been working on CLEF in the context of different classes/projects at McGill. I'm planning to make a merge/change in git:

"Stable" will be merged into (i.e. *become*) the "master" branch. From then on, "master" is going to be the main development branch. "Stable" -which should be working at all times- is going to be used for builds/distributions, e.g. for teaching purposes and projects. Changes which are specific to projects, as well as development of certain experimental features should go into dedicated branches which can eventually be merged into "master". I will also make a "Les Gestes" branch from the current "stable" branch.

So if you still have developments going on you should push them to "stable" (unless you are already using a specific branch) before I do the merge.

Cheers and Happy 2013!
Marlon

[clef-development] Change in OSC-namespace

[Schumacher M. <mar...@mu...>]

Hey,

This is just to inform you that I'll change the osc-naming scheme of audio modules in clef so they include the "~" in their osc-address.
For example, instead of "/input.1" we will have "/input~.1". I am testing this currently on a local "osc-module-naming" branch and am intending to merge this into the stable branch of the repo soon. Note, that this will break downward compatibility, i.e. older pieces (including events and messages following the old convention) won't work anymore.

Marlon

[Clef-development] Hello World!

[Schumacher M. <mar...@mu...>]

This is a tes for the CLEF-development list.

Marlon