Roesgarden 15.10

[folderol]

Thought this might be of interest

The Rosegarden team is pleased to announce the release of version 15.10
of Rosegarden, an audio and MIDI sequencer and musical notation editor
for Linux. One tester comments, "You'll be pleased to know that this
puts Rosegarden ahead of all the other sequencers I've tried for all CCs
including bank changes, program changes and NRPNs."

http://www.rosegardenmusic.com/

With this major bugfix release, Ted Felix untangled a very old problem
with instrument parameters that stumped quite a few developers over the
years. Tito Latini joined the project briefly, and went on a bit of a
rampage, fixing bug after bug. Yves got in on the effort, and
contributed several important fixes. Even Michael wrote a little code
here and there.

This is one of the best releases we've turned out in years, and we
strongly encourage everyone to upgrade immediately!

BUG FIXES

* Fix various bugs with control rulers: control items outside the
segment,
add and/or move control items after horizontal zoom, recorded MIDI
CC after
horizontal zoom
* Fix MIDI export with events before the bar 1 of the composition
(bug 1258)
* Fix importing banks from soundfonts (bug 1417)
* Fix double note-offs in playback (bug 1427)
* Fix split points during MIDI import (bug 1429)
* Fix scrolling while drawing loop/range in notation/matrix views
(bug 1222)
* Also fixed scrolling for control items in notation view
* Fix noteoffs in loop mode (bug introduced in r14092)
* Fix midi input after r14095
* Fix problem with sustaining notes while adding notes with the
pencil tool
* Also avoids moving playback position in playback mode, allowing
editing of
a loop in real-time
* Fix subordering of grace notes added before Indication events (bug
1215).
If we add a grace note before an Indication event, the event of the
grace note
precedes the indication. If we add an Indication event where there
is a grace
note, the inserted event precedes the grace note
* Fix drawing of the control ruler in notation view after horizontal zoom
* No weird message with synth plugin and pedal sign in notation
editor (bug
1424)
* Ignore duplicated noteoffs immediately. Also avoid a useless event-type
zero (SND_SEQ_EVENT_SYSTEM) when a noteoff is duplicated
* Fix event scheduling in DSSI synth (bug 1109). Before the bug fix, an
immediate event could occur after a future event and if the
immediate event
(realtime) was a note, it was time shifted and shortened (also with
zero
duration)
* Fix black space beside track headers (bug 1441)
* Fix persistent invisibility on rests (bug 633)
* Fix several interrelated bugs involving performance vs. display
duration
causing cut and paste operations on notation quantized notes to behave
strangely (bug 1440)
* Fix erroneous split of rest when inserting triplets (bug 980)
* Fix excessive warning dialogs during step recording (bug 1445).
Avoid step
recording unless the edit view is the active window. Fail silently
when
inappropriate tool is selected, rather than bombarding user with
cryptic errors
* Fix DSSI synth used with unsuitable channel setup after stop-recording
* CMI: Fix potential memory corruption
* Fix segfault if a Segment is not in a Composition
* Use getGreaterDuration() where it is opportune (reduces
duration-related
glitches)
* Fix selection drawing after mouse-button release with
matrix-velocity tool.
* Fix bug #1446 First step: A segment which is not linked with a still
existing segment is no longer flagged as "linked" when saved in a
.rg file.
Second step: A segment previously linked then left alone when
others segments
have been deleted is now copied into the clipboard as a plain
segment and no
longer as a linked one
* Fix segfault in ~EventSelection (bug 1449)
* Fix copying a linked segment with arrow tool and Ctrl+move (bug 1450)
* Fix settings memory in the quantize dialog (bug 1447). (It turns
out this
had been broken for five years!)
* Fix rests after "Remove Notation Quantization" command
* Fix duration in "Fix Notation Quantization" command
* Event quantize command doesn't change segment duration
* Fix "Open hand cursor is obnoxious" (bug 1452)
* Control rulers handle volume and expression controllers properly
(bug 1451)
* Limit event duration in "Fix Notation Quantization" command
* Normalize rests in "Fix Notation Quantization" command
* Fix the region to normalize the rests during the quantizazion
* Fix the position of the last micro event of a segment
* Ignore quantized events moved outside the segment
* Don't move events outside a segment in notation view
* Update selection drawing after editing in velocity ruler
* Update selection drawing in matrix view when a segment status is to
refresh
* Use MidiBank::partialCompare() instead of op==
* MidiBank::operator==() is a full comparison of all fields as is proper.
partialCompare() compares all fields
except name (bug 1443)
* Discover and fix two more bugs similar to Bug #1443
* Fix notation time and duration in linked segment (bug 1453 and
numerous related, unreported bugs)
* Constant thickness for a selection in matrix view
* Optimize the range to normalize the rests after quantization
* "Paste events" command doesn't change the time/duration of a segment
* Fix snap to grid in matrix view
* Fix rare track height issue when recording; if recording caused the
track heights to change, and stopping also caused the track heights to
change, the height of the TrackButtons would get out of sync
* MidiFile: Improve alien chunk handling; findNextTrack() now implements
alien chunk skipping as recommended by the MIDI spec
* MidiFile: Improve header chunk handling; Also reduced the scope of
some variables in parseTrack() to make the code a little easier to follow
* Fix 1455 and other related problems with LilyPond complex alternate
endings
* Fix broken MIME type so our files display in graphical file
managers with our icons again (fixes 1454)
* Fancy repeat endings should now be correctly handled in LilyPond export
* Fix translation of error messages from LilyPondExporter
* Fixes bug #1439, MIDI Import Modifies Bank Selects. Now,all bank
selects
and program changes are imported as-is. Once
a track is imported, the events at time zero are checked to see if
any of them can be moved to the Instrument configuration

NEW FEATURES

* Velocity ruler enhancement: Change the velocity items of the notes
selected
in matrix or notation view; Without selection, pick and drag a
velocity item
* Improve MIDI file conductor track handling on import (r14227)
* Change track/segment naming:

Previously, tracks created from different channels in a MIDI track
would be named "Imported MIDI". Now, they have the same name as the
MIDI track they came from.

Previously the MIDI instrument name was used to name the segments.
Now it is added to the end of the track name in parens.

Segments are now named after their tracks.

If no names are found, we fall back on the general MIDI program
names.

OTHER PEOPLE WHO CONTRIBUTED TO ROSEGARDEN DEVELOPMENT

* Tito Latini

[dakylla]

why oh why doesn’t rosegarden support LV2

[folderol]

Simply because there is no-one to code it

[bluebell]

Rosegarden supports LADSPA and DSSI. So if there was a DSSI-version of Carla ...

[folderol]

So if there was a DSSI-version of Carla ...

Don't tempt me...

May a refer people to this?

I sometimes wonder if we are reaching the point where more code (and effort) is being dedicated to supporting all the different interfaces than is spent on the actual functionality of programs

[folderol]

But anyway, I wouldn't speak too much while maintaining an alternative version of a very popular software.
The code and effort spent on supporting an alternative could be very well spent supporting and improving the original, specially when the current developers have been open about this.

Why do you continue with this?
I've said all I want to and was quite prepared to let the matter drop, but you drag it up again where there is no actual context, why?

Here's a thought you might like to consider.
What do you think would be the reaction if the Ford Motor company were to tell Nissan they should stop making cars and apply all their efforts to improving Ford ones? After all, Ford is by far the older (and presumably more experienced) company. They use exactly the same fuels, and run on the same roads.
Closer to home, there are about half a dozen sequencers available on Linux. Is that wasted effort? Should they all be dropped and only the oldest one be developed?

Here's another thought.
I didn't grab the lead role in Yoshimi. I didn't even want it. I was asked to take it on (you don't need to know who by or how many asked). However, the more I learn the more I think I'm doing the right thing. It would seem others agree.

And a final thought.
Although I've been using it since it was first forked, I have never attempted to tell anyone else they should use Yoshimi in preference to ZynAddSubFX, so who do you think you are to tell anyone what they should do?

Now please end this.

[ssj71]

I don't want to just jump on the bandwagon, but I have several thoughts on this issue:

Why do you continue with this?
I've said all I want to and was quite prepared to let the matter drop, but you drag it up again where there is no actual context, why?

You are right that this was kind of brought up out of context, but I think this is an issue of resource scarcity and this seems like an easy way to give you more time to work on rosegarden. Its hard to agree to disagree on this issue when you yourself are wishing for more people/time to code other projects.

Here's a thought you might like to consider.
What do you think would be the reaction if the Ford Motor company were to tell Nissan they should stop making cars and apply all their efforts to improving Ford ones? After all, Ford is by far the older (and presumably more experienced) company. They use exactly the same fuels, and run on the same roads.

Actually motor companies collaborate quite often. My Toyota Corolla is almost identical to my brothers chevy/geo prizm. Its not rare for them to share parts between brands. And who knows, maybe fords wouldn't be so rotten if Nissan helped.
Comparing open source, community driven software to proprietary vehicle manufactures isn't a strong analogy. But hey since were here, lets talk about Saab. They were bought out by GM, they were told to produce a car identical to some existing GM vehicles. Just change the body a little and the logos, were the instructions. Saabs engineers insisted that they improve the design to the point that the end result shared only a very small percentage of parts with the GM sister vehicle. This caused great delay and waste of resources. But Saab did this several times, until GM sold the division because it made no money. The buyers went bankrupt fairly soon after. The cars were built very well, but cost too much in development.
The moral I'm trying to illustrate is that a divergent fork is expensive. The community of linux audio developers is very small, so seeing effort put into a parallel but separate code base is kinda painful.
The worst thing I see with this is that the presets are becoming less compatible between the two. This is bound to cause user frustration. You have made many wonderful presets with Yoshimi, but if they aren't useable in zyn, then we have to have both installed.

Closer to home, there are about half a dozen sequencers available on Linux. Is that wasted effort? Should they all be dropped and only the oldest one be developed?

As mentioned by falk this is slightly different, since they weren't really based on the same code. Really, though, maybe they should. One of the top complaints I hear around here is dissatisfaction with linux sequencers. If more of us could pull together, wouldn't it improve? Obviously that is unlikely, but that doesn't mean that we shouldn't.

Here's another thought.
I didn't grab the lead role in Yoshimi. I didn't even want it. I was asked to take it on (you don't need to know who by or how many asked). However, the more I learn the more I think I'm doing the right thing. It would seem others agree.

Regardless by who or how many, do you consider it possible that users were misguided? I understood that yoshimi was the better sequel to zyn, which was not the case at all, but that was the opinion of the community for a long time. Perhaps it still is. I was asked to maintain yoshimi at one time. The users mean well of course, but do not understand the details the developers do.

Fundamental took a great deal of time outlining the differences and explaining the history, you seem to just want to dismiss any discussion and everybody just pretend this situation doesn't exist.

And a final thought.
Although I've been using it since it was first forked, I have never attempted to tell anyone else they should use Yoshimi in preference to ZynAddSubFX, so who do you think you are to tell anyone what they should do?

That seems very ethical. I am glad you do not degrade other's projects. We are NOT trying to degrade your work, we're trying to prevent duplication of effort when development resources are very scarce. Yoshimi is the fork, so it makes sense to merge things back into the base project. Why are you against this? You can continue working on different features than fundamental while working on the same code base.

Now please end this.

I'm not a confrontational person. I do not want to aggravate you, but I do want you to reconsider moving all the good parts of Yoshimi into zyn so we have 1 better synth rather than 2 synths that are almost the same but this one has these couple features different.

[Luc]

I do not want to aggravate you, but I do want you to reconsider moving all the good parts of Yoshimi into zyn so we have 1 better synth rather than 2 synths that are almost the same but this one has these couple features different.

Why should folderol reconsider moving the good parts of Yoshimi into Zyn? Yoshimi is free software, right? So if whoever develops Zyn (ssj71?) thinks there is something interesting in Yoshimi, take it. That's what the GPL is for.

[ssj71]

I do not want to aggravate you, but I do want you to reconsider moving all the good parts of Yoshimi into zyn so we have 1 better synth rather than 2 synths that are almost the same but this one has these couple features different.

Why should folderol reconsider moving the good parts of Yoshimi into Zyn? Yoshimi is free software, right? So if whoever develops Zyn (ssj71?) thinks there is something interesting in Yoshimi, take it. That's what the GPL is for.

Because 2 people are working on the same thing. There is no violation of GPL, but having 2 of the same thing that are slightly different and incompatible is not a situation I'd like to have. Think of jack1 and jack2. Luckily those have remained API compatible for the most part and are nearly feature equivalent. Now imagine they drifted apart so that some programs only work with jack1 and some with jack2. It would cause a huge fragmentation of our tools and cause all kinds of frustration. As is they cause a lot of confusion. I'd love those two projects merge together but the respective authors have made it clear that they will never do so. I hope folderol will be more reasonable.

The current zyn developer is fundamental. He has been focusing largely on the deep design flaws in zyn and has made great strides in improving the code. He is still working on different things than folderol has been focusing on for Yoshimi. But why can't we have 1 program that has both folderols and fundamental's improvements? So far it just looks like its because 1 of said developers doesn't want to collaborate. Fundamental has expressed willingness and desire to help folderol merge in the improvements made in yoshimi and work together on zyn. These features are not his priority so he will not take the time to just take those changes for a long while. They are not easy to merge, and will take effort on folderols part, that is a deterrent. The changes need to be broken up into small chunks that can be reviewed, merged, and tested individually. Its going to be work.

Thats why we're trying to have a calm conversation about it, for an improvement of the whole community. I spent a long time composing my reply yesterday. It was not a rant. I hope everyone can really consider both sides of this discussion. Folderol is absolutely free under protection of the GPL to do whatever he wants. I think thats great. Thats why I champion the GPL. But it doesn't mean we can't try to have a conversation about this when several developers feel strongly that a merge would improve things for everybody. Should not an open community encourage each other to do what they see as best practices? If folderol is not willing to collaborate he should just say so explicitly, and we'll be forced to accept that he has made up his mind and won't be persuaded. He hasn't made such a statement to my knowledge yet.

[Luc]

OK. Thank you for the clarification.

[glowrak guy]

Should not an open community encourage each other to do what they see as best practices? If folderol is not willing to collaborate he should just say so explicitly, and we'll be forced to accept that he has made up his mind and won't be persuaded. He hasn't made such a statement to my knowledge yet.

You are using terms of intimidation. Folderol freely shares the results of many quality developer man-hours.
You've got many better things to do, than creating a villain, where there is none.

[ssj71]

Should not an open community encourage each other to do what they see as best practices? If folderol is not willing to collaborate he should just say so explicitly, and we'll be forced to accept that he has made up his mind and won't be persuaded. He hasn't made such a statement to my knowledge yet.

You are using terms of intimidation. Folderol freely shares the results of many quality developer man-hours.
You've got many better things to do, than creating a villain, where there is none.

I don't want to create any villian. Folderol surely is not a bad guy. I apologize if it seems like I'm trying to intimidate. My meaning is that I still have hope that he is not AGAINST the idea of a merge and combining efforts rather than duplicating them. Until I lose that hope I'd like to persist in discussing the benefits and drawbacks of merging.

[folderol]

This entire thread has become farcical.

People are claiming things that simply demonstrate they actually know nothing at all. As for the demand that I make a 'statement'... What is this, some kind of political campaign? I don't feel under any obligation at all, however there are a few things that just might give pause for thought - though I'm not especially hopeful.

Those of us working on Yoshimi (yes, US, that cooperation thing) have been totally open about what we are doing. We invite opinions, listen to the ones we get and are happy to make changes to suit our users.

When I was first put in charge of the code, there was a lot I didn't know, and at a LAC a few years ago I was asking all sorts of questions. I will never forget one person who just said "Yoshimi must die". I was shocked and simply walked away. What else could I do?

On numerous occasions I have contacted the Zyn devs with ideas, detailed bug reports and compatibility questions. I have only once had a request for what extensions we've added. I wrote a long and detailed reply. I have only once been told anything about feature additions to Zyn (and even that was rather oblique). I've had to find out by looking myself.

The codebase of Yoshimi, although considerably developed has a clear and obvious lineage back to Zyn 2.4.0. However, Zyn 2.5.1 is almost unrecognisable. There are swathes of code I simply cannot follow at all. How then am I supposed to offer any work?

After literally years of discussion on LAU, the Zyn and Yoshi lists, we embarked on a major upgrade of the code for instruments, banks & roots. At the time there seemed to be no interest on Zyn. It took three of us months to complete, then link up for MIDI access as well as a significant re-write of the UI. My current compositions depend heavily on these controls now, and I know I am far from alone. This isn't something you can just hand over as a patch. If anyone wants to port it they are welcome, and as usual, I'm prepared to spend time answering any questions.

Yoshi has been remarkably stable for a very long time. There have been bugs of course, but we attack them as a high priority. Having a fairly rapid release schedule helps. I can't remember the last show-stopper. Sometime during that period, for about a year Zyn could not re-load large patches - not even ones it had just created. As I typically compose with 10-12 such sets, that made it completely unusable - and yes, I reported it as soon as I discovered it.

At LAC2015 I presented a workshop. I was extremely careful to ensure I discussed only common features. I was promoting both together as a unified whole. After the workshop finished there were a number of people who asked for specific features. One of those attending went to the trouble of noting these down and later sending to our list. Every one of those requests has now been answered. Mostly implemented, but discussion had on why two could not be.

Throughout all of this we have made strenuous efforts to ensure we remain sound compatible on instrument patches. Recently this produced a surprising result.

There is plenty more I could say, but have no desire to do so. However I fully expect more ill-considered complaints, which I will now ignore.

[j_e_f_f_g]

folderol,

You know your codebase, as well as what the working relationship is between yoshi and zyn devs. Therefore, you are in the best position to judge how best to utilize your time/talent. If you deem that you can get more done working on your own fork (for whatever reasons), rather than spending time trying to merge two, now-divergent codebases, then you should do the former. It's all about getting work done. Let someone else who feels otherwise about his time/talent do any such merge, if there is such a person. And if no such person comes forward, that's life, folks.

Nevermind falktx. If he has had a disagreement with someone, he loves to derail that person's threads by dredging up that off-topic axe to grind. This ain't the first time he has done it, and you're not the first person. (And he'll even do it to people whom he claims are in his "block list". Guy doesn't even know how to work a filter. I wish this forum had a feature to block certain people from being able to read one's threads. He'd then be the first person I've ever "blocked").

[ssj71]

alright. My questions have been answered well enough. I see that this isn't working the way I'd hoped. I just thought 1 synth that does everything well would be better than 2 that sound the same and each one does a few things better than the other. I am in full realization that every developer is free to work on whatever they want. And I'm glad for that. Its why I use open source.

As for the demand that I make a 'statement'.

I'm sorry I came off as demanding. I just hoped that perhaps you would consider it and wanted to discuss the idea, since I've never had the chance to talk to you before. You have made your intentions plenty clear. Thanks for answering.

Throughout all of this we have made strenuous efforts to ensure we remain sound compatible on instrument patches.

This is quite comforting to me. I appreciate your assurance.

Zyn 2.5.1 is almost unrecognisable. There are swathes of code I simply cannot follow at all. How then am I supposed to offer any work?
...This isn't something you can just hand over as a patch.

These are the sort of reasonings I was trying to learn. They are valid concerns.

Anyhow, sorry for upsetting you so.