Zynewave's Forum Page

Beta5:

Resizing a note event by dragging either the start or the end of the note will resize all notes in a multiple note selection. The resizing is done in realtime instead of on mouse release.

—

The suggestion of a resize option dialog on mouse release is not practical, as the resizing is now done in realtime. Support for proportional/percent resizing could be implemented either by an alternative key shortcut on clicking, or by adding a new “Split/Resize Note Events” dialog. This dialog can have a number of different edit options. One of these could be “resize notes” with a related percentage value input box. Another edit option could be “split notes into even slices” with a value input box. That satisfies a previous FR on this thread. Other edit options could be “split notes on quantize grid”, “split notes at edit cursor”, etc.

@Pigini wrote:

a good read @wikipedia about software versioning:
http://en.wikipedia.org/wiki/Software_versioning

Thanks. It seems there are no common version numbering systems that are tailored for purely incremental updates. Judging by the replies in this topic it will be difficult to replace the current x.xx numbering with something we all think makes sense. I think I’ll just continue with the current system, to avoid the confusion of introducing a new version format.

Beta4:

Enabling the “show quantization button panel” option in the piano roll region properties will show a panel of shortcut buttons to the left of the piano keyboard. Clicking the buttons will set the editor quantize value. Ctrl+Click will quantize the start of selected events. Alt+Click will set the duration of selected events.

Also added “alt+click+drag left/right to resize” and “alt+click+drag up/down to adjust velocity” options. If you have both these options enabled, then the direction you drag determines which edit action is performed.

@jpleong wrote:

We could also attach cute names to accompany each .[revision] such as fruits or types of canines and include a pertinent cartoon logo for each.

😆

The “Bugs Bunny Edition” instead of “2.09”. Worth considering.

@Conquistador wrote:

I would simply explain on your website that Zynewave does not offer upgrades. Even that explanation is not needed until 2.99…many months or longer from now.

But people would still expect a 3.0 release coming out within 1-2 year after a 2.0 release, as is the normal practice. It was your comment on the VIP topic about the purchase page changes, that made me realize that I need to disassociate the version numbering from peoples expectations when they see a x.xx version format.

..updates named after the month they are released…so if you release an update in March simply call it March 09. If the next update follows in June…then Jun 09.

“Zynewave have released a Feb 09 update for Podium”

Some would read that as Feb the 9th. (and not 2009).

Sometimes there are also more than one release within one month, so year+month is not sufficient.

@pj geerlings wrote:

But I would like to suggest the 9.xxx versioning for this year is probably adequate for the vast majority of users and a simple explaination “somewhere” should clear up any residual confusion

For people that may not know the reasoning behind it, it may appear as an attempt to inflate public opinion of Podium by jumping from 2.09 to 9.01. I fear that it would be the subject of ridicule on forums like kvr.

If the problem is too many digits in “2009.1”, an alternative would be to remove the period in the old version numbers, and present the version as “build 209”, “build 210” etc.?