Re: [Rosegarden-devel] Wiki Broken?
On Sun, 5 Feb 2023, at 14:38, Ted Felix wrote: > I can't edit pages anymore on the wiki. No edit buttons. Might be a > clue: > > Writing /var/www/sites/rosegardenmusic.com/wiki/data/meta/start.meta failed Ah yes, sorry. That was indeed a clue. Should be fixed now I hope? Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
[Rosegarden-devel] Site hosting and wiki code updated
I've just moved the Rosegarden site to a new server and updated the Dokuwiki instance to the current stable version. Everything should work unchanged, and it looks ok to me at first glance, but if you find anything missing or messed up please do let me know. Thanks! Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] [rosegarden:code] New commit [r16122] by cannam
On Sat, 9 Apr 2022, at 13:54, Ted Felix wrote: > Interesting. svn should be really stable, so introducing a conflict > should require a monumental amount of effort. I have a scripted setup for the various sites I host, that keeps a record of which revision and which version control system each site is currently checked out from. I tiredly ran the wrong admin command that (among other things) updated the wiki site to what it thought was the current version - this should have been a no-op, but its record was out of date, so it tried to update to an old version, resulting in conflicts against the files that had been changed locally. I do have most stuff scripted, but I managed to outwit the scripts this time. (The reason it had the wrong revision id recorded comes from another quirk of svn - that after you commit something, a subsequent svn info still shows the previous revision until you next do an svn update to sync with the repo. I think I understand why this is the case, but I also think it's possibly the single maddest feature in svn.) Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Bug Tracker Cleanup
On Mon, 31 May 2021, at 14:26, Ted Felix wrote: >I just went through the bug tracker and did some cleanup. Closed a > bunch of OBE, unreproducible and fixed bugs. We're now down to 37 open. Remarkable work! I wonder when they were last at these levels. Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Precompiled headers
On Sat, 17 Apr 2021, at 16:48, David Faure wrote: > I'm pretty sure that the limitation was that qDebug() is fully on or off. I just did a bit of archaeology. The answer doesn't seem to be all that interesting, sadly! Before CVS revision 2861 (2002-08-10) we were using the KDE debug stream with a single "debug area" everywhere, and we had no macro to abbreviate the kdDebug() bit in the source code, so it appeared like this everywhere: kdDebug(KDEBUG_AREA) << "message" At rev 2861 we acquired two new debug area values, KDEBUG_AREA_NOTATION and KDEBUG_AREA_MATRIX, and rev 2862 the following day introduced the RG_DEBUG, NOTATION_DEBUG and MATRIX_DEBUG shorthands: NOTATION_DEBUG << "message" At that point any debug output outside of the gui/ file hierarchy was still using cout/cerr. That changed in rev 2969 (2002-08-26) when we got sequencer and sequence manager debug areas as well. So it looks as if the RG_DEBUG type macros were introduced purely to avoid typing kdDebug(..) everywhere, since we already had the separate debug areas defined before those macros were added. Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Precompiled headers
On Sat, 17 Apr 2021, at 15:59, David Faure wrote: > Instead of the RG_DEBUG macro "hack", I recommend using qCDebug() to make it > possible to enable/disable debug output by category. Can anyone recall why we introduced the RG_DEBUG macros in the first place? Our debug was always a wrapper for QDebug, so there must have been some limitation of QDebug that we wanted to work around rather than (e.g.) wanting something that could be used separately from Qt. But I don't remember what that limitation was. I was wondering about this recently in the context of another project in which I used (cargo-culted really) something similar to the RG mechanism, then found I couldn't remember what the advantage of it was supposed to be! Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Wiki Backup Request
On Wed, 7 Apr 2021, at 20:03, Ted Felix wrote: >Hey Chris, can you fire off a wiki backup when you get a chance? Done! Thanks for the notification Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Switching to git
On Tue, 30 Mar 2021, at 12:52, Ted Felix wrote: > Still, I should probably re-run against the root dir just for fun to > see what it looks like and how long it takes. I had a look at the svn repo history at the root, and it actually goes back further - to 2000-04-04, a few hundred commits before the first one you have there. Evidently that first commit in Aug 2001 must correspond to another early rearrangement. All of this was actually done in CVS of course and converted to Subversion later - in fact, now I think about it, the change you mention in 2006 where all the code suddenly appears is probably when we first started using Subversion. I imagine we moved the converted CVS history into a subdirectory so as to store other things like the website in the same repo. Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Switching to git
On Sun, 28 Mar 2021, at 14:07, Ted Felix wrote: > I think I have everything I need then. Very amused by the automated commit email Sourceforge sent out - "15580 new commits to Git" and I really thought it was about to list them all, until thankfully it cut off after a hundred with "And 15480 more commits." I notice the early ones have very incomplete actual changeset content, often including changes only to the "meta" stuff like build files even where the commit log talks about extensive code changes. I think this is because at some point we made a wholesale move of all the actual source code files, I guess either because we switched from having only the source tree in svn to following the svn trunk/tags/branches convention, or because we added the website etc at the root level and moved the code down to rosegarden/ - or even both. So, many of the early commits were changing file paths that are not actually located within the root of the repo as you are now seeing and converting it. I don't know whether that's fixable - it would involve remapping the paths in a way that definitely constitutes fakery; I think I tried to do this when I was messing around a decade ago but failed and gave up - and it certainly isn't likely to be important. You've likely already noticed this and decided it isn't worth doing anything about, but I thought I'd bring it up just to be annoyi- I mean, thorough. Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Switching to git
On Sun, 28 Mar 2021, at 14:07, Ted Felix wrote: >Found it in the mailing list archives, September 7, 2012, "version > control repositories"... > > https://sourceforge.net/p/rosegarden/mailman/message/29780710/ Oh well discovered - I had quite forgotten the details. I'm fairly sure I haven't looked at the subject again since then, so I don't have anything more up-to-date to offer. Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Fwd: Re: [Rosegarden-user] Controlling play/stop/rewind from external DAW (Ardour)
On Wed, 17 Jun 2020, at 14:19, D. Michael McIntyre wrote: > After doing a bit of spot research on this as a translation problem, I > think I'm going to view this as English trying to impose its sense of > political correctness on the other languages of the world. The original terms came from English speakers trying to impose some sort of icky sense of humour on terminology. Why shouldn't English speakers try to put right their own stupidities? Who else should? Maybe this is just hopeful, but it would be nice if it were an opportunity to make more sense, rather than less. Let's face it, the original metaphor is functionally weak as well as rather gross. "Follower" in particular strikes me as something that should be more translatable, making more sense in the process, than "slave". The whole concept after all is about following. But I'm aware that literal translations like that can turn out very awkward, and of course it's ultimately a question for the translator. Might be interesting to know what other applications are doing - what do Ableton do in Spanish for example I wonder? Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Fwd: Re: [Rosegarden-user] Controlling play/stop/rewind from external DAW (Ardour)
On Fri, 12 Jun 2020, at 14:04, Chris Cannam wrote: > Happy to make such a commit, especially since it was I who introduced > the terms into the Rosegarden code in the first place. Leader/follower? > Source/follower? Generator/follower? I went for source/follower. Leader somehow seems still a bit unnecessarily anthropomorphic to me. I intentionally haven't updated the translation source strings in a way that would make them map to the same translations as before - since the existing translations are generally literal, it seems like it would be better to re-translate. Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
[Rosegarden-devel] Fwd: Re: [Rosegarden-user] Controlling play/stop/rewind from external DAW (Ardour)
[from rosegarden-user] On 6/6/20 12:17 PM, stefano franchi wrote: > 2. In Rosegarden's Midi Sync preferences, selected "accept Start, Stop, > and Continue", and set to "slave" as MIDI MMC and MIDI TCM Speaking of which, we should definitely rename these. Not only the zeitgeist but also just the right thing to do - these terms were always a weird and unpleasant choice that we only happened to use because they were standard, and they're becoming less standard while still being weird and unpleasant. Happy to make such a commit, especially since it was I who introduced the terms into the Rosegarden code in the first place. Leader/follower? Source/follower? Generator/follower? Ableton uses leader/follower I think, not sure about others. Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] FastVector Test Suite?
On Wed, 19 Jun 2019, at 14:06, Ted Felix wrote: >Since I'm making changes to FastVector, it sure would be nice to be > able to test it. It looks like its intent is to provide some sort of > performance improvement. So, I assume someone (Chris) at some point had > a test suite to confirm actual performance improvements. It would be a > start anyway. Nothing jumps out at me in the "test" directory. > >Do we have anything for testing FastVector? The short answer is no, and the sanest thing may be to remove the class entirely. This class dates (in one form or another) to a time before widespread use of the STL, so it would likely have been the only vector class in early projects that used it. It also differs from std::vector in that it expects you to be inserting in the middle, and so it was very much faster for some use cases. It would certainly have been measured at the time. I have no idea whether any of those tests survived I bet there is no worthwhile performance difference now, within the limited extent to which the class is used in Rosegarden... so any time spent writing tests for it is almost certainly better spent writing tests for the weird Composition::ReferenceSegment thing that inherits (!) from it, then rewriting that so as to use normal containers like a sensible class would, and dropping FastVector. Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Standard fix for MIDI timing swings?
On Thu, 14 Mar 2019, at 11:26, Sami Jumppanen wrote: > RG says the timer is "system". I once tried to select HR, but it jammed > the whole computer, power button reset was needed. If you have an audio interface active, then one of the PCM timers that Rosegarden should be offering in the preferences (whichever one corresponds to the ALSA interface in use) ought to perform more stably. I don't know about jitter, but it should be guaranteed not to lose sync with the audio at least. I think the only other solution is to use a kernel that prioritises timers in such a way as to make the system timer option work properly - this was the normal behaviour of an RT kernel ten years ago - but I'm not sure whether such a kernel is still readily available. Ideally Rosegarden would use JACK MIDI when JACK audio was in use, and that would avoid any of this. Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Standard fix for MIDI timing swings?
On Fri, 1 Mar 2019, at 22:21, D. Michael McIntyre wrote: > Come to think of it, I know there have been perennial problems with one > of the advanced timers that have caused endless mayhem. I ran lsmod and > I have snd_hrtimer loaded. I looked at the startup debug stream and see > that Rosegarden is picking "system timer." That sounds right. Vague > memory is that Chris would have preferred the HR timer, but it was > unstable, and given more recent discussion, it still is, so Rosegarden > defaults to something that usually works. My rather faint recollection is it went something like - System timer: always available, but not always reliable because various power-saving things can mess with it - before those adaptive things appeared, we had the choice between reliable-but-jittery 100Hz stock kernel and reliable-and-clean fixed-rate 1000Hz timer settings available in multimedia kernels. I don't know whether multimedia kernels with such timers still exist - HR timer: good if working, but used to be very unreliable, able to lock up the whole system - soundcard timers: good if you have an audio stream running (e.g. if JACK is in use against the same soundcard) but of no use otherwise, which is why they can't be the default Who knows, things might have changed in the last couple of decades. And there must surely be better ways to do this in new code - this choice was always a crap one. > I wish time hadn't dulled my once sharp memory so much. Ah, yes. Welcome to the... wherever we are. Time goes faster as you get older, of course. So the things you're trying to remember, which you think of as recent, are more than a decade old - that would have been a while back at any age. Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Buggy code in MidiEvent
On Mon, 3 Dec 2018, at 11:43, Chris Cannam wrote: > While I'm here I'll see about fixing a few of these. I've checked and fixed (or in one case just left an explanatory comment about) the ones listed at the bottom of this email. I haven't fixed any of the large number of inconsistent nullptr checks, or the exception stuff (catching by value). I think the least intrusive way to fix the former is probably also rather labour-intensive, sadly. The latter ought to be amenable to automation I guess, but I don't have more time to look at that. Chris [E] V560 A part of conditional expression is always false: singleStaff. NotationScene.cpp 1707 [R] V547 Expression 'i > 5' is always false. SegmentParameterBox.cpp 323 [E] V547 Expression '""' is always true. LilyPondOptionsDialog.cpp 64 [E] V773 The function was exited without releasing the 'testFile' pointer. A memory leak is possible. RIFFAudioFile.cpp 561 (and the following two) [E] V601 The integer type is implicitly cast to the char type. MidiEvent.cpp 181 [R] V674 The '0.1' literal of the 'double' type is compared to a value of the 'int' type. Consider inspecting the 'm_connectingLineLength > 0.1' expression. StaffLayout.cpp 1028 [S] V601 The string literal is implicitly cast to the bool type. FileSource.cpp 902 [S] V783 Dereferencing of the invalid iterator 'i' might take place. IconStackedWidget.cpp 126 [S] V783 Dereferencing of the invalid iterator 'beatTimeTs.end()' might take place. CreateTempoMapFromSegmentCommand.cpp 119 [S] V783 Dereferencing of the invalid iterator 'm_segments.end()' might take place. StaffHeader.cpp 250 [S] V670 The uninitialized class member 'm_intervals' is used to initialize the 'm_size' member. Remember that members are initialized in the order of their declarations inside a class. Tuning.cpp 394 [E] V557 Array overrun is possible. The value of 'submaster' index could reach 64. SequencerDataBlock.cpp 325 ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Buggy code in MidiEvent
On Mon, 3 Dec 2018, at 11:43, Chris Cannam wrote: > [S] V670 The uninitialized class member 'm_intervals' is used to > initialize the 'm_size' member. Remember that members are initialized in > the order of their declarations inside a class. Tuning.cpp 394 > First one to be attributable to Michael, I think. The author mentions > that this is not common - I thought that compilers warned about it, > which would explain why it's not common but not why this example > persisted. Think I was misled by svn there - not Michael's code but an "external submission". Also, this isn't picked up by the compiler because the problem is not that the initialisers have a different order from the declarations, but that the declaration order is already wrong for the dependencies involved. Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Buggy code in MidiEvent
On Mon, 3 Dec 2018, at 04:55, D. Michael McIntyre wrote: > On 12/02/2018 05:37 PM, David Faure wrote: > > > where sharpflat is a std::string, and tonality is an int. > > This code looks very suspicious indeed. Was it means to convert the int to > > a std::string? > > Ancient code written by one of the original founders, so it's anybody's > guess what was meant here. Exactly what David suspects, I think - the author (not me, though I was the last person to touch this code) probably intended to convert the int to a string. This is in debug code that I don't think is ever used and was presumably never tested at all. Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Website Not Updating
On Thu, 7 Jun 2018, at 04:19, Ted Felix wrote: >I committed changes to the website 9 hours ago and the website hasn't > updated. I suspect it needs to be kicked somehow. OK, it was a problem with ssh key authentication. The site is updated now, and I think the auto-update should be working again. Chris -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Website Not Updating
I'll take a look! Chris On Thu, 7 Jun 2018, at 04:19, Ted Felix wrote: >I committed changes to the website 9 hours ago and the website hasn't > updated. I suspect it needs to be kicked somehow. > > Ted. > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Rosegarden-devel mailing list > Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] website hosting move
On Thu, 8 Feb 2018, at 13:59, Chris Cannam wrote: > Should be working now, please try again. I notice the email notification > of an edit to rg-bugs list isn't showing up -- looking into that one > now... And that looks to be fixed now too. Chris -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] website hosting move
On Thu, 8 Feb 2018, at 13:55, Chris Cannam wrote: > On Thu, 8 Feb 2018, at 13:49, Ted Felix wrote: > >Can't save edits to the wiki now. It just loses them. Preview works. > > Gotcha, looking into it. Should be working now, please try again. I notice the email notification of an edit to rg-bugs list isn't showing up -- looking into that one now... Chris -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
[Rosegarden-devel] website hosting move
Quick notice that I'm going to move the rosegardenmusic.com site to a different host at some point this week -- probably tomorrow. It shouldn't really change anything; it's just a newer VPS at the same hosting provider. I'll follow up to this email when I've made the switch. Chris -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] --no-sequencer
On Sun, May 1, 2016, at 10:12 AM, David Faure wrote: > How about I rename --no-sequencer to --no-sound, so we have only one > concept (I would then merge isSoundEnabled() and isSequencerRunning() > since it's the same concept). "--no-sequencer" dates from when the sequencer was a separate process rather than a separate thread. IIRC it essentially meant "don't start the sequencer process, and ignore any actions that would normally depend on it". I think it was mainly useful on systems where the soundcard configuration wasn't working properly, so as to edit a composition without having to fix your ALSA config. It seems fair enough to me to merge it with "--no-sound", giving one option that basically means "don't try to open any of the system-specific sound drivers". Chris -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Can I clean up the XFT code?
On Tue, Apr 26, 2016, at 11:08 AM, David Faure wrote: > Can I delete the code inside #ifdef HAVE_XFT, to keep the codebase clean > and less confusing to newcomers? Speaking as the perpetrator, that would be fine with me. Chris -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] ROSEGARDEN 15.12 RELEASED
On Thu, Dec 31, 2015, at 06:27 PM, Ted Felix wrote: > On 12/31/2015 09:32 AM, D. Michael McIntyre wrote: > > == ROSEGARDEN 15.12, codename "Peace" RELEASED == > >Thanks, Michael. > >Found one issue... > >From the tar file, a debug build with tests (a default debug build) > is not possible My one test was to unpack the tarball & try a default release build using Qt5 -- it worked fine. (Though I've never done a Qt5 build of RG before and so had to dig around a bit to find out how to enable it.) Chris -- ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Ads on the list?
On Thu, Nov 26, 2015, at 07:48 AM, David Faure wrote: > Is this blurb, in all of our messages, expected? They've been putting ads there for many years -- at least 8, looking back at my archives. No idea why they went missing for a while recently, maybe they're having trouble getting advertisers or something. Chris -- Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140 ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Terrible gdb startup time when using the shared library
On Sun, Nov 22, 2015, at 09:27 PM, Yves Guillemot wrote: > That's a very long patch and the way it works is interesting. > I was totally unaware of gcc __attribute__((visibility()) There is also the option of listing symbol visibility in a script file (--version-script=blah.map) at shared object link time. Not sure whether that would work out any better in the end, but it has the advantage of not changing the source code. Chris -- ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] installed Rosegarden fails
On Mon, Nov 16, 2015, at 09:50 AM, David Faure wrote: > I suggest to retry from scratch the release-build (with no args) and > debug-build, both uninstalled and installed. What's the proper way to restore an existing checkout to "from scratch" condition, as far as cmake is concerned? I just tried the default build and then a debug build, but using "cmake ." in the root directory (in contravention of the instructions that are now in the README) instead of a build dir. I did that because it's what I used to do when we used cmake before, and it's etched in the muscle memory. It actually worked fine -- first time around I got a static binary (at least in terms of RG-specific dependencies) and the second time I got something with a separate RG shared lib. The static binary worked correctly when copied to a different directory as well, no problems with absent resources. Only problem is that the outputs are created in src/ rather than the root dir, which could be confusing, especially if an old rosegarden binary is left over in the root dir as well. I then decided to try a build dir, so I created a directory called build, cd'd to it, ran "cmake .." in that directory... and it didn't do anything -- no makefile created in the build dir. Presumably it found all its stuff already built in the directory above and just left it as it was. Hence my question at the top. Chris -- Presto, an open source distributed SQL query engine for big data, initially developed by Facebook, enables you to easily query your data on Hadoop in a more interactive manner. Teradata is also now providing full enterprise support for Presto. Download a free open source copy now. http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140 ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] cmake buildsystem
On Sun, Nov 15, 2015, at 12:42 PM, D. Michael McIntyre wrote: > Speaking for myself only at this point, it would not be difficult to > convince me to abandon dear old SourceForge. In case this should turn out to depend on me in any way, let me just say that I wouldn't get in the way of whatever was necessary to move to a different hosting provider. One specific thing would be if we were also moving the rosegardenmusic.com site (which I currently host), e.g. to github pages or whatever other hosting equivalent -- I'd have no objection to making that switch, so don't worry about any friction on my part if the momentum is there with everyone else. Chris -- ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] cmake port done, some questions left
On Fri, Nov 13, 2015, at 08:37 PM, David Faure wrote: > All done (for Qt4 at least) [...] Worked nicely here. I might rely on this as a reference for CMake in the future -- it's especially informative because I knew what the old Makefile did so I can compare them. About the tests, I'd have thought that since running them is (always supposed to be) fast, but building them is slower, it ought to make sense to run them every time they're built. When I said RG used to have a few tests, it wasn't actually the three in the test dir that I was thinking of -- there was another handful of tests lost in history somewhere that completely stopped working. Probably a decade ago. I can't remember what they tested or what happened to them, though I assume they exist in an old revision somehow. Chris -- ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] cmake port done, some questions left
On Sat, Nov 14, 2015, at 01:55 PM, David Faure wrote: > > Right now they are fast, but over time they will grow, and you guys will > get really annoyed at being slowed down in the edit-compile-run cycle by > 1 minute of unit tests running. If it takes more than a tenth as long to run as it does to build, then it isn't a unit test. And if you're annoyed by a minute of tests running, you're going to be far more annoyed by ten minutes of tests building (which is there is also that question about whether to build them or not). As long as everything is happening in-process it should be quite reasonable to run the tests every time they're built, and when there's no CI, it seems to me like a good idea from a practical point of view as well. (This is normal practice in some other projects I've worked on -- if the tests aren't automatic you won't run them, so they're automatic. But there are so many ways to slice this stuff and there certainly isn't any firm common ground.) Chris -- ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] cmake buildsystem
On Fri, Nov 13, 2015, at 11:10 AM, David Faure wrote: > Static libs are just a convenient way to handle "a bunch of .o files", > as far as build systems are concerned. Exactly -- there's not a lot of difference between libsomething.a and $(SOMETHING_OBJECTS). > Well, let's come back to the svn vs git discussion later One day git will be superseded by something else, and hopefully it'll actually have a user interface. At Rosegarden's geological timescales, 'tis but the blink of an eye. "There will one day be lemon-soaked paper napkins. Till then there will be a short delay." Chris -- ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] cmake buildsystem
On Fri, Nov 13, 2015, at 08:08 AM, Chris Cannam wrote: > in that, although I guess you'd only save much time overall if you don't > have to re-link multiple shared library objects as well (i.e. if you're > rebuilding after a change that is local to only one of them). ... or, of course, if you're linking multiple executables, such as unit tests. Which is where we came in! Clearly I should shut up now. Chris -- ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] cmake build system by David Faure
On Wed, Nov 11, 2015, at 10:44 PM, D. Michael McIntyre wrote: > If you missed it on the SourceForge traffic, David Faure offered to > contribute a new cmake build system with unit tests and all the other > benefits we've been missing since the giant port of several years ago. I saw that, and was intrigued enough to go back and check what we thought about it back in the day. Here's my post on this list about the disappearance of CMake scripts (April 2009): http://sourceforge.net/p/rosegarden/mailman/message/22158414/ Here's what you had to say the last time (that I could see) someone asked about it (December that year): http://sourceforge.net/p/rosegarden/mailman/message/24256772/ So to summarise: * The CMake scripts worked OK day-to-day, but none of us at the time felt we had enough of a grip on them to keep them working during the Qt3-Qt4 port (which also moved away from KDE) * For that port, I made a Makefile that just built whatever code it found -- on the assumption that all necessary libraries were available -- and although that ended up quite complex, at least it worked. So we stuck with it at the time and I just added an autoconf layer * People mostly dislike maintaining build systems and that means they're reluctant to even try to understand them -- the autoconf system apparently won out because it's less of a black box so you can figure it out in the end from relatively little knowledge If you (as de facto maintainer) reckon the current system isn't holding up well, and someone is offering to replace it using a system that worked all right the last time we used it, that seems very reasonable to me. (Not that you have to pay any attention to me these days, since I no longer do anything around here, but I'm trying to offer a helpful point of view.) Hopefully a CMake setup should be simpler than last time around anyway, since RG no longer uses KDE and has far fewer optional dependencies. The only thing that puzzles me is -- why is it necessary to switch build systems just to add unit tests? A test is just a small program, it shouldn't be hard to build. Chris -- ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] cmake buildsystem
On Thu, Nov 12, 2015, at 05:57 PM, David Faure wrote: > On 11/12/2015 04:38 AM, Chris Cannam wrote: > > The only thing that puzzles me is -- why is it necessary to switch build > > systems just to add unit tests? A test is just a small program, it > > shouldn't be hard to build. > > This isn't exactly true. A unit test is not just a standalone program, it > uses classes from the application. So the application can no longer be a > single monolith, it needs to provide libraries that the unittests can link to. I'm inclined to think of a unit test as another application built using the same code but happening to have a different entry point. You don't have to have libraries to do that, still less shared ones, but if you do use static libraries, it's still not all that complicated to do. It strikes me that switching to a different build system (regardless of which one) is always a lot more work than that. Still, I'm not here to argue about it, I just wondered what the motivating problem was for you. I'm not especially fond of shared libraries because of the potential for installation versioning problems -- I really like the fact that RG these days is, aside from system libraries, a single executable. Certainly it would link faster, but although linking RG used to be rather onerous, it can't be that bad for most developers now -- on this year-old laptop it now takes (goes off and runs "rm rosegarden ; time make") a whole 1.3 seconds. Anyway, it's clear you have a warm enough welcome for the idea that you should certainly go for it and see how it turns out. Chris -- ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] [rosegarden:code] New commit by titola
On Sat, Sep 19, 2015, at 06:55 PM, Tom Breton (Tehom) wrote: > Excellent! I'd just like to add to the general spirit of approval, and say that I've really enjoyed reading the commits list recently. It's a *bit* painful seeing other people having to work so hard because of some of the nonsense that we introduced back in the day, but it's a pleasure to see such care in the craft as well. Chris -- ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Qt5
On Mon, May 19, 2014, at 04:33 AM, Ted Felix wrote: r13706 fixes the issue with ftp transfers not setting an http status code for isAvailable(). I've reverted isAvailable() to its original logic (with a comment added, so it is slightly different in appearance). This commit is another candidate for inclusion in Sonic Visualiser. That looks good to me. Thanks, I've also pulled across the changes to SV. Chris -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Qt5
On Sat, May 17, 2014, at 05:46 PM, Ted Felix wrote: This issue should directly affect Sonic Visualiser, Chris, so you'll probably want to bring in this change there as well. Oh very nice, thanks. I have seen the symptom sometimes but had not yet tracked down the cause. Chris -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Qt5
On Thu, May 15, 2014, at 01:09 AM, Ted Felix wrote:
Chris, the ftp bug is in isAvailable() and should affect Sonic
Visualiser. Here's my fixed version (minus the debug output).
bool
FileSource::isAvailable()
{
waitForStatus();
bool available = m_ok;
// If everything's ok and we have a status code
if (m_okm_lastStatus) {
// We have success for any 2xx status code.
available = (m_lastStatus / 100 == 2);
}
return available;
}
An alternative would be to make sure successful ftp transfers set
m_lastStatus to 200. This might be a better solution.
Hi Ted -- thanks for looking into this. It's true, I don't think I ever
tested ftp transfers after the Qt5 update...
I do think the alternative solution might be better, in this case -- I
spent a while looking at that function and thinking that doesn't look
right, it shouldn't be defaulting to returning m_ok, the default should
be that the file is *not* available unless we've actually discovered
that it is. Having worked through the logic, I now think in practice
this will work because the last status is always set non-zero when
initialising a remote transfer, but I'd prefer if this function made the
dependency clearer.
I can't remember at what point we can first determine that an ftp
transfer is successful -- the http status I think is set to 2xx as soon
as the successful headers come back, before the content transfer
happens, which is what we want here. If you're in a position to test
this with ftp easily and get the status set in the appropriate place,
that'd be great.
Chris
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Qt5
On Thu, May 15, 2014, at 12:17 PM, Ted Felix wrote: On 05/15/2014 06:51 AM, Tim Munro wrote: Do test QNetworkAccessManager with .rg files. I discovered an annoying tendency to automatically expand zipped files, even when they are suffixed .rg. It seems to work fine for me. My test file is very small, though. Was there anything interesting about your test file? Is it possible it's the server that notices the file is gzipped, and magically gives it an XML content type with gzip encoding? If the Qt code had at the same time become able to handle such encodings, then that might come out as a regression overall for Rosegarden as you describe. Chris -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Qt5
On Thu, May 15, 2014, at 08:11 PM, Ted Felix wrote: Or does rg handle uncompressed .rg files properly? I'm pretty sure it did at one point (when using the KDE library stuff), and it probably should... Chris -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Qt5
On Thu, May 15, 2014, at 08:43 PM, Chris Cannam wrote: On Thu, May 15, 2014, at 08:11 PM, Ted Felix wrote: Or does rg handle uncompressed .rg files properly? I'm pretty sure it did at one point (when using the KDE library stuff), and it probably should... ... though if you get an uncompressed file but it still has a .rg extension, that is a bit weird. Not sure I'm convinced (from that bug report) that it is a server bug though. I would have interpreted those headers to mean the server sent a file of type application/x-gzip and then gzipped it again in transit (because it was gzipping everything), which would be inefficient but perfectly permissible. For it to be a server bug, the server would need to both mark it with content-encoding gzip and then *not* gzip it (instead passing the existing file verbatim). I don't see how you could know from that bug report whether that was happening or not. Chris -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Qt5
On Tue, May 13, 2014, at 11:41 PM, Ted Felix wrote: What is the recommended way to open a URL in rg? Erm, I wouldn't be surprised if the class that implements the feature was added and then the feature itself was never actually wired up... Probably best to do a File - Open URL as Michael suggests (this is what SV does, though it's called Open Location... in there). Chris -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Qt5
On Sun, May 11, 2014, at 09:55 AM, Tim Munro wrote: By far the ugliest large change involves preserving the remote-url capability of the FileSource class. This class comes originally from Sonic Visualiser. There is a version updated for Qt5 (using QNetworkAccessManager) in the SV source tree, see http://code.soundsoftware.ac.uk/projects/svcore/repository/entry/data/fileio/FileSource.h and .cpp. The purpose of the class is to provide the same file handle abstraction for files opened locally and URLs opened from remote locations. It is used in for example RosegardenMainWindow::openURL(). I updated Sonic Visualiser to Qt5 a little while back and it was fairly straightforward, though Rosegarden would certainly be harder. I just counted five #ifdefs against Qt version 5 or higher in the SV code -- with these it has continued to work fine with Qt4, and I no longer pay much attention to whether I'm building against Qt4 or Qt5 on any given machine as it doesn't seem to make much difference. Chris -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Update on tuplet rewrite
On Fri, Nov 15, 2013, at 10:05 PM, D. Michael McIntyre wrote: On 11/15/2013 04:40 PM, Chris Cannam wrote: released, most probably, but if it *just* gets merged and released without really being exercised, it won't work. I agree, though it's a problematic situation in that I just never deal with tuplets much, and any testing I do will be naive. We really need some tuplet nut other than Tom himself to check out the branch and go crazy with it. I know there are some true tuplet nuts out there. Users? Any volunteers to exercise the big tuplet rewrite? It doesn't just call for the tuplet-crazy though -- Tom's work will affect quite a lot of things, including (hopefully) big improvements to auto-beaming and the like. Really anyone who enters or records-and-edits notation is likely to see some changes. You should definitely mess around with it even if you never venture outside your most familiar workflow. Chris -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Update on tuplet rewrite
On Fri, Nov 15, 2013, at 09:50 AM, Chris Cannam wrote: Rebuilding once more without debug (btw I had already confirmed the crash -- without debug -- on a build from clean) Chris -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Update on tuplet rewrite
OK, here's what I did: * build rev 13554 from clean without debug * open the Ravel example piece * select just the right hand segment, open in notation editor * find the very first 12-tupleted note in the part * select that note only * hit the delete key on the keyboard Program received signal SIGFPE, Arithmetic exception. 0x00539eaf in Rosegarden::TimeSignature::setInternalDurations() const [clone .part.14] () (gdb) where #0 0x00539eaf in Rosegarden::TimeSignature::setInternalDurations() const [clone .part.14] () #1 0x0053be40 in Rosegarden::TimeSignature::getNumDivisions(int) const () #2 0x00594578 in Rosegarden::DirtyNodeFinder::storeDirtyNodes(Rosegarden::MeterTreeNodeArgs) () #3 0x00594b93 in Rosegarden::DirtyRanges::fixAll(Rosegarden::Segment) const () #4 0x0059b890 in Rosegarden::EraseCommand::eraseInSegment(Rosegarden::EventSelection*) () #5 0x0059b910 in Rosegarden::EraseCommand::modifySegment() () #6 0x0045b190 in Rosegarden::BasicCommand::execute() () Chris -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Update on tuplet rewrite
On Fri, Nov 15, 2013, at 10:30 AM, Chris Cannam wrote: Program received signal SIGFPE, Arithmetic exception. 0x00539eaf in Rosegarden::TimeSignature::setInternalDurations() And here's valgrind: ==7241== Process terminating with default action of signal 8 (SIGFPE) ==7241== Integer divide by zero at address 0x81141E17B ==7241==at 0x539EA9: Rosegarden::TimeSignature::setInternalDurations() const [clone .part.14] (in /work/rosegarden/build/big-tuplet-rewrite/rosegarden/rosegarden) ==7241==by 0x53BE3F: Rosegarden::TimeSignature::getNumDivisions(int) const (in /work/rosegarden/build/big-tuplet-rewrite/rosegarden/rosegarden) ==7241==by 0x594577: Rosegarden::DirtyNodeFinder::storeDirtyNodes(Rosegarden::MeterTreeNodeArgs) (in /work/rosegarden/build/big-tuplet-rewrite/rosegarden/rosegarden) ==7241==by 0x594B92: Rosegarden::DirtyRanges::fixAll(Rosegarden::Segment) const (in /work/rosegarden/build/big-tuplet-rewrite/rosegarden/rosegarden) ==7241==by 0x59B88F: Rosegarden::EraseCommand::eraseInSegment(Rosegarden::EventSelection*) (in /work/rosegarden/build/big-tuplet-rewrite/rosegarden/rosegarden) ==7241==by 0x59B90F: Rosegarden::EraseCommand::modifySegment() (in /work/rosegarden/build/big-tuplet-rewrite/rosegarden/rosegarden) ==7241==by 0x45B18F: Rosegarden::BasicCommand::execute() (in /work/rosegarden/build/big-tuplet-rewrite/rosegarden/rosegarden) etc. Chris -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Update on tuplet rewrite
On Fri, Nov 15, 2013, at 06:27 PM, Tom Breton (Tehom) wrote: Possible approaches: * Roll that part back. Much as I hate to just give up, it's causing Chris's crashes and this weirdness, and it was really just supposed to be an optimization and minimize what got rewritten. That is probably the right thing to do, although it'd be nice to figure out why the crash happens as well! My problem with this, first time around, was basically that it was too intrusive when editing existing material. But being both simpler and more intrusive is going to make it more likely to be right and comprehensible when entering new stuff. (What happens when you edit material with wildly differing recorded and notation times? It should presumably use the notation times as source material...) I would like to encourage everyone who can to test this branch -- I think the approach looks like a very sound one, enough to have provoked me from my slumbers, but there are many possible things that can go wrong and my testing time is very limited. It should get merged and released, most probably, but if it *just* gets merged and released without really being exercised, it won't work. Chris -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Update on tuplet rewrite
On Thu, Nov 14, 2013, at 01:56 AM, Tom Breton (Tehom) wrote: OK, I have rewritten the tuplet rewrite so it handles the Ravel example, keeping the 6-lets. Also, as Chris wanted, I have made it handle dirty subunits of a bar instead of always doing a while bar. I was only going to do this if needed for performance, but since its absence was felt, I went ahead and did it. Hm, now if I delete one of the 12-tuplets (or try to insert a shorter note over the top) it crashes with an FPE. I don't have full debug (can get it if you like) but it's roughly #0 0x00539eaf in Rosegarden::TimeSignature::setInternalDurations() const [clone .part.14] () #1 0x0053be40 in Rosegarden::TimeSignature::getNumDivisions(int) const () #2 0x00594578 in Rosegarden::DirtyNodeFinder::storeDirtyNodes(Rosegarden::MeterTreeNodeArgs) () #3 0x00594b93 in Rosegarden::DirtyRanges::fixAll(Rosegarden::Segment) const () #4 0x0059b890 in Rosegarden::EraseCommand::eraseInSegment(Rosegarden::EventSelection*) () #5 0x0059b910 in Rosegarden::EraseCommand::modifySegment() () #6 0x0045b190 in Rosegarden::BasicCommand::execute() () #7 0x00471e5a in Rosegarden::CommandHistory::addCommand(Rosegarden::Command*, bool, bool) () Chris -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Tuplet rewrite branch committed
On Fri, Nov 8, 2013, at 03:07 AM, Tom Breton (Tehom) wrote: Fundamentally, the idea is to have a bulletproof bar rewriter (Rewriter) that takes as much time as it needs to notate everything nicely. Sounds like an excellent principle. On first test it looks a bit too eager to override decisions the user has already made elsewhere in the bar. For example, try opening the Ravel test piece, finding the section with 12-tuplets in the right hand and then selecting and deleting one note from within any of the tuplet groups. In trunk, when a note is deleted, the rest of the group remains intact as a 12-tuplet (as do the other groups in the bar). However, the note that is deleted is replaced with un-tupleted rests, whose displayed duration is therefore not correct (this is one of the many things that makes an overhaul a good idea in principle). In the new branch, the rest that replaces the deleted note is calculated correctly, but at the same time the whole bar is rewritten into triplets, which isn't desirable either. It's a mistake to assume there is any one canonical structure for the notes in a bar and that they can be automatically rewritten correctly based only on their timings. If the user has introduced groupings already, they should be respected. Chris -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Tuplet rewrite branch committed
On Fri, Nov 8, 2013, at 05:32 PM, Tom Breton (Tehom) wrote: Oh, it doesn't just go by timing, it also goes by existing beamings and tuplings. Oh -- very good to hear the detail you've thought about this in already. * It will force a new group ID for tupleted groups that don't already start with a fresh group. That's because it fears using a non-tupleted beaming for a tupleted group. The Ravel example shows that this is perhaps too strict. Can you explain in more detail what you mean by this? Particularly that don't already start with a fresh group. I'm particularly concerned in the Ravel example by the fact that the *other* 12-tuplets in the bar were also split into triplets, not only the one in which the immediate edit happened. * It always tries the natural metrical decomposition first. Ie, mostly binary splits. a la TimeSignature::getDivisions(), or something else? A tree decomposition using this hierarchy is the way I always meant to rewrite autobeam on insert, and I take it your code handles autobeam instead in this branch. (The old autobeam code dates from me as an undergrad pissing about with the problem until it appeared to work mostly, without ever thinking about what the problem truly consisted of. While it'd be great to lose the old code because it was basically crap, it'd be a bit sad to lose it so near to its 20th birthday.) On a similar note, Rewriter also decounterpoints everything. I have two questions about that: * Are there any use-cases where it's important to *not* split-and-tie across barlines? Having to do that would really make this difficult, and it seems just wrong anyways. * Are there any use-cases where it's important not to decounterpoint? That I can handle by just not rewriting except to split at barlines, and I take the flag to do so, I just don't act on it because I'm not sure it's the right thing to do. I think these are related to the Ravel question actually. The problem there is that you're doing something that *is* correct, in isolation, except that the user has already given some other preference. People interested in notation will get awfully troublesome if they decide to express something in an unlikely way and then you go and change it. It may be that the right thing is to tie all of this to autobeaming or some other option for rapid, generally correct entry, which can be switched off, and let expert/opinionated users and those trying to match an existing score do their own thing separately. That said -- to answer the actual questions -- I think since we got the ability to overlay segments, there is probably no case in which the old half-arsed counterpoint is a good idea when entering new music. It's just the opinionated-user case that's the problem. Chris -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] [rosegarden:code] [r13407] - tedfelix: Add logging for time consuming file deletion
On Fri, Sep 13, 2013, at 01:19 AM, Tom Breton (Tehom) wrote: AFAICT there is no good reason for it to do that. It doesn't actually keep the data between sessions. It struck me as an expensive substitute for std::map. I should think comes from the former two-process architecture (sequencer and GUI) in which we used shared memory blocks to pass data from one process to the other. For no very compelling reason, we happened to use file-backed shared memory (mmap'd files). Offloading storage space from RAM to disk is not part of the deal, because these files are all mapped into RAM anyway. There is no good reason to use this sort of structure now, except that the code was there already and refactoring was easier than rewriting. This way at least concurrent access code is localised and the necessary locking is tolerably clear (since the structure is shared between threads). Chris -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Subgroups latency compensation off by one
On 18 April 2013 23:30, D. Michael McIntyre rosegarden.trumpe...@gmail.com wrote: Yeahbut it's an ID to a member of a container. I read it as take the ID of the first thing in the container, then use an ID one lower than that. It seems random at best, destructive at worst. This code makes my brain hurt now as well (how on earth did we ever decide that using plain ints in different ranges to represent different kinds of ID was a good idea?) but I agree with you on this, the thing returned by *connections.begin() is an instrument ID not a counter or index. So it could be, for example, 1 which represents the first synth instrument (synth instruments have IDs starting from 1). Subtracting one would give you , which would theoretically mean the 8000th MIDI instrument (because MIDI instruments occupy the 2000-1 range) which is not at all a meaningful thing here. There's obviously some interesting mystery being hinted at here, but I don't quite see what it is either. Chris ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Subgroups latency compensation off by one
On 19 April 2013 06:37, Holger Marzen hol...@marzen.de wrote:
On Thu, 18 Apr 2013, D. Michael McIntyre wrote:
Probably because there are tons and tons of situations in STL and Qt
where standard idiom is to iterate through container classes with
iterators, and the standard language is
for (some_class_iterator i = some_class.begin();
i some_class.end(); ++i) { ...
Yes, that's what I think. But then we have tons of logical inaccuracies
because we don't see i some_class.end() but i != some_class.end().
That's the normal idiom when using iterator objects, because although
they are comparable for equality, they aren't always comparable for
ordering (in other words, there is not necessarily any operator
defined).
Think about two arbitrary iterators pointing into a hash table, for
example -- although you can easily determine whether they're the same,
you can't quickly determine which one appears first in the table.
Michael's use of instead of != above was probably itself a typo, in
other words, although not one that matters hugely (it would either
work properly or fail to compile).
Note that there is no semantic difference between ++i and i++ in this
context either -- not in C++ and not in C. Both of them have the same
effect, which is to increment i, even though they return different
results -- and in the context of a for loop as above, the result is
not used for anything so the difference is irrelevant.
That is, the ++i in
for (i = 0; i 10; ++i)
says increment i, return the incremented value, and do nothing with
it because it's not assigned to anything. The net result is simply to
increment i. While the i++ in
for (i = 0; i 10; i++)
says increment i, return the value before it was incremented, and do
nothing with it because it's not assigned to anything. The net result
is again simply to increment i.
Some old-school C programmers would write ++i instead of i++ here
because it was theoretically faster to compute -- it just meant
increment a value instead of having to copy, increment, and then
return the old value. Of course in practice, every C compiler would
optimise this so that the two were the same so the distinction was
irrelevant.
With the advent of container iterators in C++ the difference became
theoretically interesting again, as potentially copying and
incrementing an iterator could be more expensive than doing the same
with an integer or pointer. Again, in practice it's not going to
matter by now, but conversely, why would anyone write i++ when it
means the same as ++i but is more semantically complex and has the
potential to be slower?
Chris
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Panning Laws revisited
On 12 March 2013 15:45, Tim Munro or...@lewiston.com wrote: Because the same panning law is always applied to both instrument and submaster Hmm.. is that a good idea? I'd have thought a stereo submaster wants either plain balance or a stereo pan, rather than a positional mono-to-stereo pan law? Perhaps I'm overcomplicating the matter in my head. Otherwise your approach sounds sensible. This subject also seems to have come up on LAD in the mean time, from a MusE developer -- http://lists.linuxaudio.org/pipermail/linux-audio-dev/2013-March/033690.html Chris -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Panning Laws revisited
On 12 March 2013 20:22, Tim Munro or...@lewiston.com wrote: Perhaps the thing to do is to leave the submaster controls as they are, basic balance controls, and save all the fancy panning laws for the individual instrument controls. Since you're doing the work here, I think the acid test is: would that be bad for *your* workflow? If not, then I think that seems like a vaguely reasonable thing to do -- fix the instrument panners, leave the submasters. Chris -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Gain problem with audio panning
On 6 March 2013 02:50, Tim Munro or...@lewiston.com wrote: Currently Rosegarden appears to be using a form of the so-called 0dB Pan Law that results in a monaural channel being considerably louder when panned to the center than when panned to either side. When I first read the code, I assumed it was a mistake, but I guess people actually do this sort of thing intentionally. As far as I'm concerned, the current code has always been a bit useless -- a consequence of someone (was it me, back in the day? not sure... if so I apologise) doing what seemed obvious without giving it enough thought. The main reason it has never changed is just inertia based on there already being sessions out there using the existing behaviour. One thing I'd say though is that this sort of thing really must be part of the saved document, not just part of the application settings. There could *be* an application setting, but it would have to be a default for new documents rather than a fixed setting for every document. It's not really OK to have sessions changing their mix balance without warning when saved and reloaded. At the very least, RG should know enough to be able to warn when a session is reloaded with a different pan setting (or when a session made before the setting was added is reloaded with a setting different from the former default). From what I've read, I'm not sure that OdB, -3dB, or -6dB setups would be useful for what I need to do. I *think* that what's usually referred to as a -3dB law is actually what you have -- i.e. -3dB in power rather than voltage. (as 10^(-3/20) == 1/sqrt(2)) Probably should check what other software thinks though, which I can't readily do just at the moment. (However, it should attenuate in the centre rather than boost at the edges -- otherwise you can load a normalised file, pan it, and it clips.) Chris -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Wiki was spammed Re: Rosegarden-bugs Digest, Vol 80, Issue 2
On 19 February 2013 04:58, D. Michael McIntyre rosegarden.trumpe...@gmail.com wrote: Oh well. There's nothing I can do about that. I changed some settings once upon a time, but Chris pays for this and it's set up the way he prefers, so... Shrug. Spam isn't much of a problem, at least. Famous last words perhaps -- we seem to be getting a string of spam registrations going on now. The wiki isn't really set up the way I prefer, as such, it's just set up some way or other that seemed to work out OK. To date it has been quite extraordinarily un-spammed, relatively speaking, but it could never last. If it starts being a big problem I guess we'll have to remodulate the shield frequencies or something. Chris -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Status: #1350 Can't Record Beethoven
On 26 October 2012 13:20, Ted Felix t...@tedfelix.com wrote: The RefreshStatus stuff appears to be an attempt to mitigate this CPU usage problem. However, it is not complete. The Segment::notify*() functions are still there and still in use. Historical note: the RefreshStatus mechanism actually predates the notifiers. It is indeed supposed to be a cheap way to handle aysnchronous updates, but I don't think it was ever expected even so that it would be called for every event while recording... Chris -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Status: #1350 Can't Record Beethoven
On 25 October 2012 09:13, Chris Cannam can...@all-day-breakfast.com wrote: don't even try to update the actual notes on canvas. (I don't have the program in front of me atm either, and I can't actually remember offhand whether we don't show them at all or update them in batches -- either way we shouldn't be having a callback per-note and no edit commands should be firing) Chris -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Status: #1350 Can't Record Beethoven
On 25 October 2012 02:38, Ted Felix t...@tedfelix.com wrote: The executive overview goes something like this Rosegarden was designed to be a MIDI editor. Then someone decided to add MIDI sequencing to it. But what's ok for a MIDI editor (very CPU intensive updates in response to infrequent edit events from the user) is not at all ok for a MIDI sequencer (constant edit events due to massive amounts of incoming MIDI data courtesy of Herr Beethoven). That's not quite an accurate characterisation -- it was always intended to be a sequencer as well. The idea is (was) that the sequencer process would operate largely asynchronously from the editor process. So when playing, the editor would write a large number of events in advance to a shared memory area, and the sequencer would play back from there. (Editing during playback would run the risk of playing the wrong thing during the edit, but would never hold up the sequencer.) When recording, the sequencer would log incoming events to a buffer and then the editor would pick them up afterwards. The main risk here of course was overflowing the buffer, but the timings should be correct so long as the sequencer thread timer was accurate. In neither case should the number or nature of editor callbacks make any difference to sequencing or recording. For the Qt4 rejig (i.e. what became Rosegarden 10.02) we merged the sequencer and editor processes -- which had previously been quite separate processes communicating using IPC mechanisms -- into separate threads in a single process. But the shared-memory architecture (all the mapped-buffer stuff) stayed the same. I'm afraid I haven't found the time to follow this bug closely, but if Rosegarden is unable to record large volumes of incoming MIDI properly, that suggests that either the inbound buffer is overflowing, or else a change during the 10.02 timescale has introduced a mutex that means writing to the buffer is no longer a safe operation for the sequencer to carry out. Or else there's been some other change that means segment updates affect recording -- segment updates shouldn't be happening in any great quantity during recording, though, because we don't even try to update the actual notes on canvas. Chris -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] svn-command still recent?
On 20 October 2012 19:12, D. Michael McIntyre rosegarden.trumpe...@gmail.com wrote: I bet Chris needs to update his script to pull website changes from the new URL. I bet you're right. I've updated the server now -- let me know if you see any problems on the site! Chris -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Discussion: Rosegarden's Latency Compensation Model
On 28 September 2012 03:32, Holger Marzen hol...@marzen.de wrote: I'd like to discuss the latencies with you that can occur and how and where they should be compensated before we actually create patches. That sounds like a good idea. I seem to remember the problem that the existing implementation ran into, was that it was initially trying to do wholly automatic latency compensation when recording -- which isn't possible, because the necessary compensation depends on what you're recording. What it probably needs is automatic compensation only for the known output latencies (e.g. effects plugins) across all track types -- which it is supposed to do, but which you've found isn't working properly -- plus easy nudges for new tracks forward and backward by common latency periods following recording, with some more useful options than the current delay setting. Chris -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] SourceForge Repo Clone Failed
On 18 September 2012 19:54, D. Michael McIntyre rosegarden.trumpe...@gmail.com wrote: Bloody hell. I'm getting a 500 for http://sourceforge.net/projects/rosegarden/ now. (It worked a few hours ago, though the page was slathered in more ads than I've ever seen.) I was going to have a look to see whether our existing file downloads had been retained -- I have a recent backup of the SVN repo, but I don't have copies of all the file releases. Were they supposed to have been carried across? If so, did that work? I sort of feel that if SourceForge can't even retain our artifacts when moving us to a new interface, there's not a great deal of point in being on SourceForge. Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] SourceForge Repo Clone Failed
On 18 September 2012 20:46, D. Michael McIntyre rosegarden.trumpe...@gmail.com wrote: On 09/18/2012 03:33 PM, Chris Cannam wrote: The repo does seem to check out OK, as well -- it just doesn't show up in the browser. Which URL? The new SourceForge has the repos at totally different URLs. svn://svn.code.sf.net/p/rosegarden/code/trunk/rosegarden -- which I assume is the new one (it certainly isn't the old one). Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] SourceForge Repo Clone Failed
On 18 September 2012 20:30, Chris Cannam can...@all-day-breakfast.com wrote: I was going to have a look to see whether our existing file downloads had been retained -- I have a recent backup of the SVN repo, but I don't have copies of all the file releases. Were they supposed to have been carried across? If so, did that work? Ah, there we are. Yes, they seem to be there. The repo does seem to check out OK, as well -- it just doesn't show up in the browser. Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] SourceForge Repo Clone Failed
On 18 September 2012 20:52, Tom Breton (Tehom) te...@panix.com wrote: The team has fairly up-to-date local copies. Chris, you're keeping those trial repositories, right? I can unveil a Mercurial repo whenever you like. Git I would have to convert again from Mercurial (I deleted the Git repo) but that's lossless. Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
[Rosegarden-devel] version control repositories
OK, in order to have something concrete to consider, I've converted a bit of history to git and Mercurial. Rosegarden's history is pretty gnarly and includes a lot of dead-end branches and relatively few sensible tags, so rather than get into knots trying to convert everything I converted only the trunk, and only back to the point where the Qt4 build was pulled across to trunk. That's still 2000-odd revisions. I've mapped the usernames as well as I could (let me know if you see any mistakes there). I used hg convert to convert to Mercurial, and ended up using hg-fast-export to get the data from hg to git. Here it is in git: https://github.com/cannam/rosegarden And here in Mercurial: https://bitbucket.org/cannam/rosegarden Presumably there would want to be an official rosegarden-release repo to do builds from -- I'm just proposing one of these as a possible starting point to clone from. So, what do you think? Developers please please pick one of the following -- [ ] I like the git one [ ] I like the hg one [ ] either is fine with me (e.g. I'm happy with both tools, or I'd clone to the other one anyway) [ ] I'd like to use a dvcs, but I'd suggest a different repo to start from (e.g. one I already have locally) [ ] I don't think we should switch from svn and of course [ ] Gah! Cannam is an arse Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] concerning bug #3560849
On 6 September 2012 06:54, Richard Bown richard.b...@ferventsoftware.com wrote: If course I'm also interested in this myself too because my R4Win updates are still so infrequent that it annoys me I have to manually merge every time I want to integrate latest. The reason you have trouble merging is that you arsed about indiscriminately with the directory structure when you made your branch. That would probably be a slightly easier thing to maintain with a newer version control system than Subversion, but only if you had been using it when you branched in the first place. Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] concerning bug #3560849
On 6 September 2012 07:39, D. Michael McIntyre rosegarden.trumpe...@gmail.com wrote: It really does seem like an excellent opportunity to change over to distributed version control. Assuming Chris is amenable. I'm broadly in favour of using a distributed system, though I don't have the same antipathy to Subversion that some do. My preference is for Mercurial, and normally I'd try to persuade people to use that over git, which I see as the C++ of version control systems, and I don't mean that in a good way -- but really I have less stake in this than anyone at this point. There's not much point in my arguing for Mercurial if all of the active developers are already using git. (I would be able to help with the transition if Mercurial was involved, e.g. converting / pruning the existing history as appropriate, but I've nothing to offer for a conversion to git.) There are all sorts of things I would love to be doing with the Rosegarden code, and much as I might prefer to do them in a Mercurial repo, it's not the version control system that's holding me back -- it's entirely my own ability to find any time for it. Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] concerning bug #3560849
On 6 September 2012 09:37, Richard Bown richard.b...@ferventsoftware.com wrote: Anyway I won't go back there. No. Won't do it. I've already bunged my branch into bitbucket anyway and you lot can just assume it a fork (or death) from now on. Will make it public once there are any deviations from what is in SF. Usual pigheadedness from Cannam. *blink* OK, I'm properly baffled. All I said was that the upstream project switching now probably wouldn't help your merge very much. Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
[Rosegarden-devel] twitter
I registered a Twitter account: https://twitter.com/#!/rosegarden_m I have never been into Twitter, but for various reasons I'm having to put a bit of practice in to it at the moment so I might as well have a go at this as well. If any of the core developers would like to help run the account, drop me a note. Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] rosegarden on Mac OS X
On 16 May 2012 00:00, Schindler Karl-Michael karl-michael.schind...@web.de wrote: Working on the audio driver is definitely beyond my scope. Testing is basically would i could do. Well, thank you for the work you've done so far -- even if the tricky bit still lies ahead, it's good to know that the rest is looking like it should be feasible. I hope I didn't come across as too grumpy in my previous mail (I probably did, sorry). Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] rosegarden on Mac OS X
On 14 May 2012 22:57, Schindler Karl-Michael karl-michael.schind...@web.de wrote: David Tisdell's advertisement on the mac X11 list dragged me in. He also mentioned my brief trial to build rosegarden on macosx. My main contribution would be setting up and maintain the fink package description. Hello there. I don't entirely know what Fink is, but I would expect that any build of Rosegarden for OS/X would just be an ordinary OS/X app, presumably packaged in a .dmg for installation into the apps folder like any other. Rosegarden uses Qt4 for its GUI, which uses Cocoa directly and is quite easy to package (depending on how many different OS/X versions one tries to support). With the exception of the audio and MIDI support and associated libraries, RG is reasonably straightforward to port to the Mac -- the problem really is the amount of development work necessary to get any sound support. As this stage the configure doesn't include any direct support for doing a sound-less build -- you'd need to hack configure.ac so as to skip the ALSA/JACK tests and build without HAVE_ALSA and HAVE_LIBJACK. (As for the other failing configure tests: the only direct reference to X11 libraries in the code is to install an error handler, which of course would be unnecessary when building without X11 as on Cocoa. dssi.h is an audio plugin format spec header, easily bundled but there's no point in worrying about it when we have no audio! And sha1sum is used to generate a build ID for support purposes.) Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] rosegarden on Mac OS X
On 15 May 2012 22:43, Schindler Karl-Michael karl-michael.schind...@web.de wrote: Is it ok to make an announcement on Rosegarden-user? Well, that certainly sounds like a nice thing to look at and there may be users who might be interested in playing with it -- but it probably isn't very wise to advertise too much a build without any sound support at all! I'm afraid establishing that it builds on the Mac is really just a necessary precondition for actually porting the audio/MIDI code. A possible start for MIDI might be to use the RtMidi support from the Windows port. For audio, JACK exists on OS/X but unfortunately the JACK code in RG is dependent on having ALSA as well, which doesn't exist anywhere but Linux. Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] rosegarden on Mac OS X
On 15 May 2012 23:00, Brett McCoy idragos...@gmail.com wrote: Probably should take a look at how Ardour handles JACK on OSX, you might be able to adapt some of those ideas. Well, the trouble is not with JACK as such -- it's the same on any platform -- it's just that the JACK audio driver in Rosegarden was the first and only audio driver written at the time, and it's entwined with the ALSA driver (that preceded it as the first and only MIDI driver) in rather unholy ways. I maintain Sonic Visualiser (http://sonicvisualiser.org) for Linux, OS/X and Windows, with both audio and MIDI support (though with far more limited MIDI requirements than Rosegarden). That has all sorts of possible audio and MIDI driver combinations, including JACK on Linux or OS/X, or PortAudio anywhere -- but it's a simpler architecture with less historical baggage than Rosegarden, and I've just never found the time to do any comparable factoring in RG (and realistically I probably never will). Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Fwd: [Rosegarden-user] Rosegarden's Future
On 13 May 2012 23:56, Cláudio Pinheiro taup...@gmail.com wrote: Rosegarden needs broad visibility by potential users, so it can generate a critical mass that would attract developers that would maintain a sustained growth and (even) better codebase and documentation. To achieve it Rosegarden must walk the multiplatform path. It must be the top priority now for the future's greater good. I appreciate this argument, and thank you for articulating it well. But I'm afraid I just don't see the evidence in other applications that broadening your user base, by porting to other platforms with a smaller proportion of developers, helps a great deal with development effort. I think that the difference between Mixxx and Rosegarden is something else. It's focus. Mixxx has a very clear purpose, every developer has pretty much the same focus, and every developer is able to exercise that purpose very clearly in testing the application. So although Mixxx has about the same number of active developers as Rosegarden, they're able to pull it along more efficiently because it's a simpler and smaller application with a much clearer goal. Compare this with Audacity, perhaps the world's most widely-used audio application -- inching along much like Rosegarden does, with a similarly-sized developer team who spend most of their time integrating occasional external contributions and trying to fix the bugs those contributions bring in. Their wider user base gives them a lot more tricky single-platform bug reports and causes years of delays to stable releases. Or the Gimp, spending the last four years on a bunch of changes finally released to a collective response of is that _it_ for the last four years? (and I'm sympathetic, but it's true that almost every change in Gimp 2.8 seems to make my life more difficult instead of easier). Or Ardour, a fine application perhaps unique among these in having had a developer working full time on it for many years, but again with only two or three really active developers and not an enormous amount of visibility. No, most of the cross-platform projects are more like Rosegarden than like Mixxx. Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] [Rosegarden-user] Rosegarden's Future
On 10 May 2012 16:18, Richard Bown richard.b...@ferventsoftware.com wrote: Current Core Dev Michael Tom Breton Daren Beattie Ian Gardner A plan for the future Dev direction if any. Having no plan is also fine. Can we also survey: How many developers are potentially interested in unit tests or other automated testing? Who thinks they might actually manage to put together a test or three, if there was a general effort to do so? Which areas (within the code) would you be most interested in trying to exercise? I know that both Daren and Ian have raised the subject before (without much response, including from me I'm afraid). Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] [Rosegarden-user] Rosegarden's Future
On 11 May 2012 17:42, Tom Breton (Tehom) te...@panix.com wrote: It would break my heart to use another test framework For what it's worth, I think it's evident that the test framework Rosegarden should be using is the Qt one. (As least, if it's any good -- which it is; it's pretty nice.) Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
[Rosegarden-devel] Version control?
Time to revisit this perennial favourite? Do you feel that Rosegarden's current use of Subversion is an advantage for the project, a disadvantage, or largely irrelevant? Would any change attract more new developers, put off old developers, both, or neither? (Please explain your reasoning!) Note that I'm a fan of Mercurial (so much so that I work on a user interface for it, http://easyhg.org) and would be inclined to suggest using that, because: 1. It's approachable for people who are used to Subversion 2. But similar enough to git that it should work for people who are occasional users of git, i.e. those who have to look up the syntax whenever they try to do anything clever 3. It feels native on Windows as well as on Linux 4. It has a consistent interface and good help But I'm well aware that I haven't been a major contributor during the last couple of years, and that at least two of the people who have (Tom and Ted) have referred to using git, while the main manager (Michael) is more comfortable with Subversion. Converting the repository retaining a sensible amount of history would be tricky (RG svn history is a mess) but possible, and I could handle it for Mercurial (but I wouldn't know how to for git). So, what are your views? (I'm not trying to call for a vote -- rather just call for opinions and get this out of the way while we're thinking about development meta-questions.) Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] [Rosegarden-user] Rosegarden's Future
[cc -devel] On 10 May 2012 13:41, Ian Gardner ilgard...@yahoo.co.uk wrote: I guess people like me are part of the problem in this regard, turn up one day, chuck something in to do with linked segments and then f. off into the sunset. Fly-by-night, here today and gone tomorrow contributors :-( Well, you could say anyone who ever wrote any of the code is part of the problem by now! I know I am. I guess one possible way to ameliorate the bejeesus, this codebase is an unmaintainable spaghetti! problem is automated testing. Well, as you know, the difficulty with automated unit testing is the sheer effort involved in writing tests (after the fact) that cover more than a tiny percentage of possible cases. [On another project I'm currently in the middle of porting some existing unit tests to a different test framework (without changing their content) just to sit better with the rest of the code. I can't believe how much work it is -- I never really noticed the initial effort of writing the tests for that code because I did it at the same time as writing the code under test, but when you look at it afterwards there's a heck of a lot of it and I simply can't imagine doing it all at once after the fact, even if it didn't actually take any real thought.] I do like the suggestion of using slightly higher-level test cases with synthetic series of commands though (given serialisable command classes). Apart from anything else, then you could supplement human-designed tests with pseudo-random command sequences or fuzz tests, which would give quite a good tradeoff of effort against effectiveness. Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] [Rosegarden-user] Rosegarden's Future
On 10 May 2012 19:32, D. Michael McIntyre michael.mcint...@rosegardenmusic.com wrote: I think even worse than that is keeping the tests working over time. We had some tests, but they didn't survive the port. But that's just another sign that they weren't terribly relevant unit tests. Even though they appeared a long time ago, they were still very sketchy tests written long after the code they were testing. If they had had a more effective coverage, they would actually have been useful in the port (by telling us whether we had broken anything) and so breaking the tests would itself have been enough incentive to fix them. Quis custodiet ipsos custodes? I think that's Latin for who will test the unit tests? Isn't it technically who will test the unit testers? I'm only a relatively recent convert to thorough unit testing, basically because I had become so used to bad unit tests written by programmers in companies who just thought they probably ought to be writing some. One thing that I found helpful in forming a better opinion was starting to think of the tests as a bit like an exam _for me_ -- do I understand the problem well enough to write a really good test for it? And I believe this question is how that Latin phrase actually originated. Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] [Rosegarden-user] Rosegarden's Future
On 10 May 2012 16:18, Richard Bown richard.b...@ferventsoftware.com wrote: Devs or Interested in Ports I'm not particularly interested in a Mac port and don't especially want one, but I'm certainly competent to make one and would try to help out if there was more general interest. (Why not particularly interested? I just don't see much evidence from other projects that it increases the active developer base, it'll only make for difficulties with users because it's not a very Mac-like app) Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
[Rosegarden-devel] code complexity, was Re: Kickstarter
On 8 May 2012 20:49, Tom Breton (Tehom) te...@panix.com wrote: * In principle we could re-merge some mapped classes with their base counterparts. They spend a fair bit of code just staying in sync, or trying to. But that's a lot of work and error opportunities just to keep things working about the way they are. This area is full of historical code that was originally designed to work with the GUI and sequencer in separate processes communicating through shared memory. Some of it was simplified (and/or thrown out) when the processes were merged in the Qt4 rebuild, but most is still there. But you still do have to be very careful with threading in this code. At the moment the mapped classes still have a distinct role as areas whose memory layouts are fixed and that are read-only on the sequencer-thread side, minimising the extent of necessary synchronisation when the structure contents change. If the sequencer used the base classes directly, we'd need much finer synchronisation, and that is difficult with the structures we're using. In fact, it's so difficult that one of the most significant causes of bugs has been improper synchronisation between readers and writers of our segment classes, _even where they are in the same thread and the same code unit_ -- e.g. in editing functions that iterate through a segment and modify some of the events in it. Mapped classes apart, the old process-communication structure gives rise to a lot of other things that make it difficult to follow the code and find bugs. For example, it's really tricky to work out who notifies who and how (in terms of classes, but also in terms of threads) when something changes like an audio file being loaded or a plugin setting being edited. The plugin architecture in general, from GUI through to audio I/O, is just crazily complex in a single-process world. * What if we used garbage collection? I haven't looked at the Boehm GC for ages, but we did consider it for RG way back in the late 90s and rejected it as too unreliable in situations where some sort of competing object lifecycle management is already in place (as is usually the case in C++ and certainly when using Qt). Of course it's clear that we made plenty of wrong decisions about memory management, so perhaps that was one of them! But I'm pretty certain that it would be surpassingly difficult to introduce into an application with such tricky existing manual memory management as Rosegarden. One of the most significant and helpful changes made in Qt for Qt4 was the introduction of more consistent expectations for memory management of Qt objects. That is, except in special cases where you're expected to know what you're doing, QObjects are created on the heap, are not copied, are passed by pointer, and belong to their parent QObjects; non-QObject objects like strings and containers are created with automatic storage and passed by value using implicit copying. This sort of consistency wasn't a feature of Qt3 or KDE3 classes and it certainly wasn't ever a feature of Rosegarden's code. I suppose that one good principle might be to identify ways in which Rosegarden's model could be incrementally moved closer to modern Qt practice. Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] [Rosegarden-bugs] SF.net SVN: rosegarden:[12854] trunk/rosegarden
On 5 March 2012 04:56, te...@users.sourceforge.net wrote: Added Elisp template code to templates/, and docs. The auto-insert-choose.el file appears to be only a symbolic link to something elsewhere in your home directory? Chris -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] emacs autoinsertion templates (Was rosegarden's license.)
On 4 March 2012 19:07, Tom Breton (Tehom) te...@panix.com wrote: Shall I submit them? Yes please! Chris -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Re rosegarden's license.
On 26 February 2012 13:10, D. Michael McIntyre michael.mcint...@rosegardenmusic.com wrote: There was a time when I cared a great deal, and felt really strongly that Rosegarden should stay with GPLv2. Now, I really don't care so much anymore, or even remember what the fuss was all about. (Digressing, now that we seem to have come to a decision about the substance of it) I'm in two minds about the GPLv3. On the one hand, it's increasingly clear that the threat the GPLv3 was intended to address is a real one. The app store delivery and installation model is going to take over the world (as much as it hasn't already), and it subverts a part of the point of the original GPL -- it doesn't make any difference whether users can get your source code, if they have no authorisation to build and install an application from it anyway. The trend toward devices that refuse to be programmed is a big problem for Free Software, and the GPLv3 tries to resist that trend -- a resistance that is probably futile but certainly principled. On the other hand, the GPLv3 is arguably the worst thing that ever happened to Free Software in terms of how it is understood by developers. GPLv2 was both fairly comprehensible and fairly close to a natural mental model of how software should be reused for many developers. GPLv3 introduces confusion: not only do we now have a choice of two licences both called the GPL with various voices on either side advocating for one or the other, but the newer one is enormously harder to understand, the two are not compatible, and the workaround for compatibility (the or later clause) is itself hard to keep track of, since it's not part of the licence itself and code in the real world often omits it. I believe (without having any figures to back it up) that there's been something of a flight to BSD among developers over the past few years, and that this is partly because of the convenience and apparent free money! angle of the app store model (to which I suppose a Free Software advocate should reply: good riddance), and partly because the appearance of the GPLv3 has ensured that GPL is now associated even more than ever with squabbling factions of pedantry that many reasonable developers don't want to get involved with. Chris -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Re rosegarden's license.
On 26 February 2012 20:25, Ted Felix t...@tedfelix.com wrote: The COPYING file is missing (I think) the or any later version verbiage. Probably need to add that at the very top before the text of the GPL. I think the COPYING file right now is nothing other than the text of the GPL. It does not contain any statement about how Rosegarden is licensed. That's in the README file. It explicitly says v2 or later. Chris -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] [Rosegarden-user] live notation view while playing midi-keyboard
On 14 February 2012 20:46, D. Michael McIntyre michael.mcint...@rosegardenmusic.com wrote: Viewing notation for an emerging MIDI segment on the fly would be difficult to achieve. I have no interest in attempting this, personally. (moving to -devel) I did actually implement this once... sort of. It was before the notation view was completely overhauled for Qt4, and I never tidied up any of the enormous number of awkward difficulties that prevented it from being actually useful, but it could be a fun thing to look at for anyone with time and an interest. The basic stub is still there, as RosegardenMainViewWidget::slotUpdateRecordingSegment, though it doesn't look as if it can ever be called and in any case it was only the tiniest part of the work involved. Chris -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] unsigned, was Re: [Rosegarden-bugs] SF.net SVN: rosegarden:[12819] trunk/rosegarden/src/gui/editors/segment
On 11 February 2012 09:53, Richard Bown richard.b...@ferventsoftware.com wrote: I was going to say that bit of smugness is going to come back and bite him in the ass but of course I didn't.. On this note: today I got a bug report on a project of mine, where the bug was arguably caused by my having used signed instead of unsigned integers. The situation was a pretty familiar one in the MIDI or audio-file handling of software like Rosegarden -- it was decoding a sequence of bytes (stored in a std::string) into a series of integer values by pulling out individual bytes and composing them by bit-shifting (take the high-order byte, shift by 8, take the next byte, add and shift etc). The problem was that the byte values were assigned to signed integers, and in some cases these came out negative, giving a completely bogus result. The proposed fix was to assign to unsigneds instead. The only reason I say the problem was arguably caused by using signed integers is that the real root of the problem is storing byte sequences in std::string in the first place. std::string is a sequence of plain char, not signed or unsigned char, so the signedness of its elements is platform-dependent. Assigning these into signed values then materialised the problem. Chris -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] unsigned, was Re: [Rosegarden-bugs] SF.net SVN: rosegarden:[12819] trunk/rosegarden/src/gui/editors/segment
On 11 February 2012 10:37, D. Michael McIntyre michael.mcint...@rosegardenmusic.com wrote: On Saturday, February 11, 2012, Richard Bown wrote: Well that was a nice little read, straight from the voice of experience. I was going to say that bit of smugness is going to come back and bite him in the ass but of course I didn't.. I rather saw it as Chris finally growing a spine. He never asserts anything with any real authority Well! Thanks fellas... Though I'm inclined to agree with Richard on this one -- reading it over again, I think smug arsehole as well. On the technical side, the real problem (I think?) is that unsigned and signed are not sufficiently distinct types -- so if you mix them in arithmetic, the signed will be silently promoted to unsigned even if it happens to be negative. This also means you can run into problems from unsigneds even if you don't intentionally use them, since library functions like std::vector::size return unsigned. If the two were completely non-interchangeable except with an explicit cast, they wouldn't cause anything like as many bugs... though they'd probably annoy even more programmers. Chris -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
[Rosegarden-devel] unsigned, was Re: [Rosegarden-bugs] SF.net SVN: rosegarden:[12819] trunk/rosegarden/src/gui/editors/segment
On 10 February 2012 04:13, tedfe...@users.sourceforge.net wrote:
No functional changes. Mainly cosmetic changes to TrackButtons. A couple
of int's changed to the more sensible unsigned.
I feel bad about popping up only to quibble about something, but
changing int to unsigned on the whole is not a very good idea --
rather the opposite.
The main problem is overflow when computed values used for e.g. loop
indices unexpectedly become negative (that is, large and positive in
the unsigned world). For example,
for (n = 0; n m - 1; ++n) { ... }
while (i k - j) { ... }
will loop rather more than expected if m == 0 or j k.
This is surprisingly common: it's one of the biggest sources of bugs I
see in code I get to review at work. It's more common in code that
does mathematical or signal-processing work than in most of
Rosegarden, but I'm sure it isn't the case that this never happens in
Rosegarden code.
I do understand that there are sound reasons one might want to use
unsigneds, and they're not only related to getting an extra bit for
the maximum positive value. For instance, unsigned overflow is defined
while signed overflow is not: UINT_MAX + 1 == 0, while INT_MAX + 1 is
undefined. But in practice, in most places where ints get used, signed
overflow is far less likely to be an issue than any problems with
unsigned arithmetic. (As an aside, this detail of the behaviour of
signed arithmetic allows the compiler to do a number of useful
optimisations if you happen to use signeds for loop counters, because
it is allowed to assume they never overflow.)
Also, of course, the standard library uses unsigneds for things like
vector sizes (although you'll notice that the Qt API always uses plain
int) so it's tempting to make everything else unsigned to avoid
compiler warnings and the like. Quite honestly though, it's far safer
to do the opposite and convert the unsigned to a signed int before you
use it.
Using signeds for values that are philosophically unsigned can also
have useful side-effects, such as in this case being able to use -1
for unset or no value, more meaningful to the reader than
UINT_MAX.
Unless you're explicitly representing a bit-addressable memory region
or something like that, I'd seriously suggest avoiding unsigned
altogether. I used to use unsigned and size_t quite a bit, and since I
realised how error-prone it was (because like most programmers, I'm
just not really good enough) I've pretty much eliminated them from my
code with only good consequences.
(This has come up on this list before, I think. Last time I had this
discussion with someone, I was amused to see this commit in one of his
projects a few weeks later:
http://code.soundsoftware.ac.uk/projects/audiodb/repository/revisions/6a5117d68ac4)
Chris
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Logical instruments is ready for a look
On 10 February 2012 18:55, Tom Breton (Tehom) te...@panix.com wrote: There may be a way to have it both ways. If that doesn't work reasonably, then I'll simply writes times as if tempo was fixed, which you and Chris have convincved me of the merits of. I think I am less convinced of this myself than Michael seems to be -- I'm not sure a richer MIDI format isn't worth having, possibly more so than tempo ramps in many situations. But it's certainly one way to do it, and the grey area is... grey. If Michael's argument is persuasive to you then you should certainly overrule me. Chris -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Logical instruments is ready for a look
On 10 February 2012 19:25, D. Michael McIntyre michael.mcint...@rosegardenmusic.com wrote: Sure it's worth having, it's just hard to reconcile a neat MIDI file with something that fundamentally can't be represented in MIDI. Is it better to mangle the durations or to put in twelve dozen bizarre tempo changes? It's better to put in the tempo changes, because you only need to put in one for each event that starts during the ramped section (so there is some logic to it, it won't look completely arbitrary and bizarre) and more importantly because that way you don't end up with less meaningful MIDI files for the far more common case where you have tempo changes but no ramps. But, this basically amounts to my saying that doing it right would be better -- when (as we've seen) doing it right is what's prevented us from doing it at all in the past. Chris -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Logical instruments is ready for a look
On 7 February 2012 20:34, Tom Breton (Tehom) te...@panix.com wrote: Mm, I doubt that would work. It does understand the RealTimes in an intermediate stage, but it converts back to timeTs. Can you remind me (sorry) what the intermediate stage is? I think one must either write out no tempo changes at all except for the initial tempo, and handle all of the note positions by converting to real time and then converting back to MIDI time in a tempo-independent way -- which would give all notes the right times but give us a relatively uninformative MIDI file, without any MIDI tempo changes in it -- or else one needs separate handling for ramps. Inserting a tempo for each note event (as you almost suggest) would probably be ideal for ramps -- otherwise, for notes during a ramp, taking the real-time difference from the start of the ramp and converting that to an elapsed MIDI time assuming constant tempo, writing that out for each note, and then ensuring that the start time was reset appropriately for the first event following the ramp. Neither way is impossible, but either is fiddly enough to explain why we haven't managed to do it already! Chris -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Trouble building logical instrument branch
On 31 January 2012 19:52, D. Michael McIntyre michael.mcint...@rosegardenmusic.com wrote: I hate Git with a passion I've developed a habit of recommending Mercurial for people with an allergy to Git who would nevertheless like to use something more modern than Subversion -- and some Git users also find Mercurial more amenable as a second VCS than they do Subversion. (I enjoy Mercurial and, like you, have never really got on with Git.) In this case, if I read it right, the problem wasn't so much the choice of version control system as the fact that two different ones (any two) were in use? Or is the root problem just that we didn't automate rebuilding the data bundle? Chris -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Logical instruments interim report
Tom -- this looks like good stuff, thank you. On 18 January 2012 19:58, Tom Breton (Tehom) te...@panix.com wrote: StudioControl::sendNRPN and sendRPN would be affected by this, but it looks like they aren't ever called anywhere. Are they used in some subtle way that escapes me? I have a feeling they were never completed and hooked up -- Richard Bown might remember with more certainty. In which case, if they're now actively wrong, it would probably be better to remove them. Chris -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
