From: D. M. M. <ros...@gm...> - 2012-09-14 18:57:56
|
SourceForge is starting to make noise about wanting to get projects moved over, so they can stop maintaining two codebases. As I recall, this move is going to wipe out our bug and feature request trackers. That's basically a good thing overall, since it's mostly a huge list of real but very minor problems we can't or won't fix, going back up to 10 years, and the whole thing smells like a fresh, clean start. I don't want to interrupt any ongoing issues where the trackers are currently and actively being used to manage something, or, at a minimum, I should at least make sure to preserve and resurrect whatever issues those are in the new setup. I have a couple of sad side projects. I'll go experiment with converting one of those over before I give additional thought to Rosegarden making the switch. In the meantime, think about what, if anything, we need to take with us from the old trackers. -- D. Michael McIntyre |
From: Ted F. <te...@te...> - 2012-09-14 20:28:04
|
On 09/14/2012 02:57 PM, D. Michael McIntyre wrote: > As I recall, this move is going to wipe out our bug and feature > request trackers. The only thing I would need would be the open bugs from the last year. I think that's only 14 bug reports. From 3427608 onward. I can certainly help transition if needed. This is pretty important stuff for the way I'm working these days. Is there any way to get some sort of quick text dump in case we want to examine the trackers after the switch/loss? It's just the archivist in me. Ted. |
From: D. M. M. <ros...@gm...> - 2012-09-15 08:50:25
|
On 09/14/2012 04:27 PM, Ted Felix wrote: > Is there any way to get some sort of quick text dump in case we want > to examine the trackers after the switch/loss? It's just the archivist > in me. I remember them saying something about new trackers replacing the old when the new site design was announced, but looking at the "convert my project" stuff, it appears that is no longer true. I don't see anything that's likely to cause any interruptions in continuity, other than a requirement that we do a fresh checkout from a different URL. I put all of my piddle projects in for conversion, and I'll see how that goes. -- D. Michael McIntyre |
From: D. M. M. <ros...@gm...> - 2012-09-15 10:49:37
|
On 09/15/2012 04:50 AM, D. Michael McIntyre wrote: > I put all of my piddle projects in for conversion, and I'll see how that > goes. It went fine, though none of the little projects I fiddled with are a speck of dust compared to Rosegarden. The biggest disruption is the need for everyone to do a fresh checkout from a different URL. I'm thinking it would probably go more smoothly if everyone gets their ongoing changes handed in, and then we freeze the repository for a day or two until I have time to get everything sorted out on the far side. There isn't a huge amount to sort out, but it's going to take some fiddling of the sort that can only be done once the conversion has taken place. It looks like some restructuring of our repository is called for. So then, what say I put in the upgrade request this time tomorrow, and go ahead and get the ball rolling? Any objections? If there are none, I'd like to get this matter dealt with while I have some spare time. It got slow at work abruptly, and SourceForge is going to compel everyone to make the change sooner or later. Let's just get it over with while I have a window of opportunity. -- D. Michael McIntyre |
From: Ted F. <te...@te...> - 2012-09-15 11:14:54
|
Fine with me, my local copy has no changes. If it did, I would just update, make a patch, and apply it once we get to the other side. Ted. On 09/15/2012 06:49 AM, D. Michael McIntyre wrote: > On 09/15/2012 04:50 AM, D. Michael McIntyre wrote: > >> I put all of my piddle projects in for conversion, and I'll see how that >> goes. > > It went fine, though none of the little projects I fiddled with are a > speck of dust compared to Rosegarden. > > The biggest disruption is the need for everyone to do a fresh checkout > from a different URL. I'm thinking it would probably go more smoothly > if everyone gets their ongoing changes handed in, and then we freeze the > repository for a day or two until I have time to get everything sorted > out on the far side. > > There isn't a huge amount to sort out, but it's going to take some > fiddling of the sort that can only be done once the conversion has taken > place. It looks like some restructuring of our repository is called for. > > So then, what say I put in the upgrade request this time tomorrow, and > go ahead and get the ball rolling? Any objections? If there are none, > I'd like to get this matter dealt with while I have some spare time. It > got slow at work abruptly, and SourceForge is going to compel everyone > to make the change sooner or later. Let's just get it over with while I > have a window of opportunity. > |
From: Tom B. (Tehom) <te...@pa...> - 2012-09-15 17:13:49
|
OK, as Michael asked, I've committed my ongoing changes. On branch update-figurations, I've added UpdateFigurationCommand to ExpandFigurationCommand. Basically, it knows about figurations you've made in the past and updates them. In order to manage this, I've added several pseudo-events: * SegmentID, a persist segment ID event. Not the same as segment name or Segment pointer, it survives save+restore etc. UpdateFigurationCommand tries to keep it conformant. * GeneratedRegion, which indicates that a region was auto-generated and where it came from. A generatedregion can be edited manually to change what sources create it, and then UpdateFigurationCommand will bring it into sync. So if you use figurations and then change your mind about your chords, one command will bring it all back up to date. Some implementation notes: * New commands: * UpdateFigurationCommand * GeneratedRegionDialog * GeneratedRegionInsertionCommand * New directory base/figuration/ I put all the shared support code here. * SegmentID.{h,cpp} instead of fattening NotationTypes.h * GeneratedRegion.{h,cpp} similarly. * SegmentFigData.{h,cpp} about scanning segments for figuration purposes. Contains some stuff that used to live in ExpandFigurationCommand. * RelativeEvent * FigurationSourceMap * FigChord - used to be * Various support in NotationStaff, NotationView, just paralleling other NotationTypes. Incidental stuff: * New support files DocumentGet.{h,cpp}. I noticed that my modest requirement to get all the active segments was dragging in not only RosegardenMainWindow.h and RosegardenDocument.h, but every header that they included. For one trivial function call! I notice this cascade happens in other files too. So I made this little file, just a namespace with two functions in it. * Fixed NotationRules' "unused" warning differently. Newer compilers complain about "foo" being assigned to and never used. It's 90% complete. Most importantly, there is NO UNDO yet. I had hoped to reveal it in a more complete state. Tom Breton (Tehom) |
From: Holger M. <ho...@ma...> - 2012-09-15 20:32:04
|
Hi all, to pan, mix and process the drums separately I have to waste one instrument (one fluidsynth-instance) per drum. Only 16 are available. Would it be possible to add more slots for synth plugins? Of course I could run fluidsynth instances as separate programs to get 16 more instruments but this adds latency and cannot be stored inside the .rg-file. Any comments? (Hydrogen is no altenative for me since it adds variable(!) delays when I route MIDI-events to it. This kills every groove.) |
From: Aere G. <Aere@Dvorak-Keyboards.com> - 2012-09-16 00:09:53
|
I have used the pan controls, and the volume (and expression) controls on individual MIDI channels (assuming the MIDI channel limitation is the limiting factor here), using Qsynth (which uses fluidsynth) for synthesizing sound (rather than the fluidsynth DSSI plugin instances). I have had a need for parallel output to two sets of MIDI channels with fluidsynth as the synthesizer. I have done this with no noticeable latency problems, though percussion instruments show latency problems more readily than melodic instruments. I use this for performing using what I call "Composite Voices". The way I did this, is to add another Qsynth "engine" (by default you get only one). It's easy to add more, and each one can have its own configuration parameters. Then I piped my keyboard MIDI output to both Qsynth engines simultaneously. Having done this, I have two sets of 16 MIDI channels, one set using the original Qsynth port as the playback device, and the other set using the 2nd Qsynth 'engine' as the playback device. I can use the pan and volume/expression controls for any of these MIDI channel voices. I do not notice additional latency for the 2nd Qsynth engine, though I do notice it uses the amount of memory required for the sound-font for each 'engine' (they don't share sound-font memory). Since the sound-font it uses is nearly 150 megabytes, this can be a problem on machines having less that 1 megabytes of RAM. I get around that problem on lower-RAM machines by using a smaller soundfont for the 2nd Qsynth 'engine'. Since I use piano/guitar sounds, I'm quite sure I would have noticed if the 2nd Qsynth engine added additional latency. I have had pieces messed up by latency before (with different causes), and know what those problems sound like. One 'fly in the ointment' on this, is that I tried this with the current (available with Ubuntu 12.04) versions of Qsynth (fluidsynth), and Rosegarden, and I could not make any other MIDI channel than 10 work as a percussion track. HOWEVER, the current development version of Rosegarden, along with the latest available version of libfluidsynth1 (used by qsynth), let me make channels other than 10 function as percussion tracks. I also verified that they responded to the volume and pan settings (though they didn't seem to respond until I selected a different track, then re-selected the track I changed). Adding an additional qsynth engine would give you 16 more such percussion instruments, and you can add more qsynth engines, each time giving you 16 more percussion instruments, probably without adding noticeable latency (though I haven't tried a 3rd or 4th qsynth engine). Anyway, perhaps this gives you some ideas of other approaches to solving your problem. I am not a Rosegarden developer, or a fluidsynth developer. However, I use these components a lot, in a lot of different ways, and am trying to teach people how to do the same. - Aere On Sat, 2012-09-15 at 22:31 +0200, Holger Marzen wrote: > Hi all, > > to pan, mix and process the drums separately I have to waste one > instrument (one fluidsynth-instance) per drum. Only 16 are available. > Would it be possible to add more slots for synth plugins? > > Of course I could run fluidsynth instances as separate programs to get > 16 more instruments but this adds latency and cannot be stored inside > the .rg-file. > > Any comments? > > (Hydrogen is no altenative for me since it adds variable(!) delays when > I route MIDI-events to it. This kills every groove.) > > ------------------------------------------------------------------------------ > How fast is your code? > 3 out of 4 devs don\\\'t know how their code performs in production. > Find out how slow your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219672;13503038;z? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Rosegarden-devel mailing list > Ros...@li... - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel -- Sincerely, Aere |
From: D. M. M. <ros...@gm...> - 2012-09-15 20:54:30
|
On 09/15/2012 04:31 PM, Holger Marzen wrote: > instrument (one fluidsynth-instance) per drum. Only 16 are available. > Would it be possible to add more slots for synth plugins? There are already supposed to be 24 slots, and that appears to be the case here. I have Synth Plugin #1 through #24 available, though I didn't actually try populating all of them with plugins and seeing if it would all work. I'm pretty sure 24 was chosen as an arbitrary number, to provide more than 16, but not so many as to be likely to crash someone's computer with the huge load. I don't think there would be major consequences increasing the number past 24, but if it's set at 24 now and you're only seeing 16, then something else is already wrong before we even go there. I had a quick look through the code and it looks likely that SoftSynthInstrumentCount (defined in src/base/Instrument.h) is being used sensibly throughout. I tried assigning plugins to slots beyond #16 and succeeded just fine. All 24 are available here. Synth plugins use high instrument ID values internally, so there is no chance of overlap or conflict, and the sky's the limit on what that could be set to, it looks like. It does not, however, look like a good candidate for something that could be set through a configuration variable. I'd expect the potential for some nasty consequences changing that at runtime. -- D. Michael McIntyre |
From: Holger M. <ho...@ma...> - 2012-09-16 06:20:49
|
On Sat, 15 Sep 2012, D. Michael McIntyre wrote: > On 09/15/2012 04:31 PM, Holger Marzen wrote: > > > instrument (one fluidsynth-instance) per drum. Only 16 are available. > > Would it be possible to add more slots for synth plugins? > > There are already supposed to be 24 slots, and that appears to be the > case here. I have Synth Plugin #1 through #24 available, though I > didn't actually try populating all of them with plugins and seeing if it > would all work. Stupid me! I didn't scroll down in the instrumens' dialog! |
From: D. M. M. <ros...@gm...> - 2012-09-23 20:46:36
|
You're on the ball, aren't you Ted? I had planned to update all the links and whatnot this morning, and instead I woke up to find it already done. Sweet! It looks like the new SourceForge is more or less functional now, except the Rosegarden for Windows subproject is still impressively broken, and they haven't even (as of when I went to bed anyway) read the ticket yet, let alone made any recommendations or fixed anything on their end. As I get time over the next few days, I want to go through the bugs and feature requests mess and figure out what to do about all that. The site docs aren't crystal clear, but I have the impression in the long run the new ticket system is the issue reporting method that's going to get support from SourceForge development staff, while the trackers are just there for backward compatibility. A migration is probably in order, but maybe not. More homework required. -- D. Michael McIntyre |
From: Ted F. <te...@te...> - 2012-09-24 04:13:37
|
On 09/23/2012 04:46 PM, D. Michael McIntyre wrote: > You're on the ball, aren't you Ted? Apparently not. The URLs I used are read-only. To checkout a version that can be committed you have to do this: svn checkout svn+ssh://us...@sv.../p/rosegarden/code/trunk/rosegarden rosegarden-svn Replace "userid" with your userid. Need to get this info on the wiki... Ted. |
From: D. M. M. <ros...@gm...> - 2012-09-24 07:36:27
|
On 09/24/2012 12:13 AM, Ted Felix wrote: > Apparently not. The URLs I used are read-only. To checkout a > version that can be committed you have to do this: > > svn checkout > svn+ssh://us...@sv.../p/rosegarden/code/trunk/rosegarden > rosegarden-svn > > Replace "userid" with your userid. > > Need to get this info on the wiki... I tried out the svn+ssh thing with one of my little side projects. I found it to be unreliable in the beginning. These days, it works, but it's still more annoying than just using https. I just confirmed that this pattern works with Rosegarden too. svn checkout --username=userid https://svn.code.sf.net/p/rosegarden/code/trunk/rosegarden rosegarden I did a test commit, and all is well at last. -- D. Michael McIntyre |