From: Matthias N. <nee...@ma...> - 2004-09-16 05:36:06
|
> From: Silvan <dmm...@us...> > > On Tuesday 14 September 2004 11:05 pm, Matthias Neeracher wrote: >> - My patch replaces references to Qt::whatever with the hardcoded >> color >> values. This is not all that pretty, but the probability of Qt::red >> being changed to a different RGB value are pretty low :-) > > Interesting. Surely that isn't really the correct way to fix this, > but I > guess sometimes there's ideologically correct, and then there's > getting it > done today. > > So what does that get you on OS-X now? It seems that Rosegarden is now basically functional, minus the actual Audio I/O, which is going to take a few weeks. I am an experienced CoreAudio programmer, but not yet CoreMidi. Furthermore, it seems that there is no formal documentation for the SoundDriver interface (or is there? I'd appreciate any pointers). > From: Guillaume Laurent <gla...@te...> > On Wednesday 15 September 2004 05:05, Matthias Neeracher wrote: > >> - My patch replaces references to Qt::whatever with the hardcoded >> color >> values. This is not all that pretty, but the probability of Qt::red >> being changed to a different RGB value are pretty low :-) > > Silvan, I see you applied this patch : please revert it. There's a > better way > to fix this without resorting to ugly magic numbers (no matter how > unlikely > they are to change). This is, of course, your call to make. I experimented with one design which preserved the symbolic Qt constants (by writing a lazy wrapper for QColor and an explicit initialization function to be called from main), but that required small changes in lots of files and colours.cpp itself was much uglier. If I had written the code in question from scratch, my instinct would have been to bundle all the colors in a singleton struct, but I suppose this design would not fit in at all with the current Rosegarden style, from what I can see. I should also point out that the file was already full of ugly magic numbers BEFORE I touched it :-) In fact, the constants I substituted happen to be precisely the RGB values that are trivial to figure out in one's head, because they only involve 0, 127, and 255. All the nontrivial colors were already hardcoded. Matthias |
From: Guillaume L. <gla...@te...> - 2004-09-16 05:59:34
|
On Thursday 16 September 2004 07:36, Matthias Neeracher wrote: > > This is, of course, your call to make. I experimented with one design > which preserved the symbolic > Qt constants (by writing a lazy wrapper for QColor and an explicit > initialization function to be called from main), > but that required small changes in lots of files and colours.cpp itself > was much uglier. > > If I had written the code in question from scratch, my instinct would > have been to bundle all the colors in a > singleton struct, but I suppose this design would not fit in at all > with the current Rosegarden style, from what I can see. That 2nd way is how I'd like to change this as well. We need to change this anyway, given that relying on the order of static initialisation is wrong, no matter if it works currently on Linux. > I should also point out that the file was already full of ugly magic > numbers BEFORE I touched it :-) Yes, for custom colors, but to have those for pre-defined ones is a bit silly. Plus we have the same problem with accidental names as you pointed out earlier. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2004-09-16 09:14:57
|
On Thursday 16 Sep 2004 06:59, Guillaume Laurent wrote: > On Thursday 16 September 2004 07:36, Matthias Neeracher wrote: > > If I had written the code in question from scratch, my instinct > > would have been to bundle all the colors in a > > singleton struct > > That 2nd way is how I'd like to change this as well. The existing colours.cpp is really a quick hack just to get all the values in one place. The original intention (good intentions, as always!) was to replace it ultimately by something configurable, or at least something that calculated some of the colour values based on the current KDE theme. Chris |
From: Guillaume L. <gla...@te...> - 2004-09-16 21:30:51
|
On Thursday 16 September 2004 11:26, Chris Cannam wrote: > > The existing colours.cpp is really a quick hack just to get all the > values in one place. The original intention (good intentions, as > always!) was to replace it ultimately by something configurable, or > at least something that calculated some of the colour values based on > the current KDE theme. I'll try to find the time to fix it this week-end. -- Guillaume. http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2004-09-18 18:18:47
|
On Thursday 16 September 2004 23:31, Guillaume Laurent wrote: > On Thursday 16 September 2004 11:26, Chris Cannam wrote: > > The existing colours.cpp is really a quick hack just to get all the > > values in one place. The original intention (good intentions, as > > always!) was to replace it ultimately by something configurable, or > > at least something that calculated some of the colour values based on > > the current KDE theme. > > I'll try to find the time to fix it this week-end. Done. Matthias, can you check if it works for you ? BTW I've also removed the last ifdefs for KDE 3.<1. -- Guillaume. http://www.telegraph-road.org |
From: Matthias N. <nee...@ma...> - 2004-09-16 15:55:53
|
> Would you continue to use JACK for audio? That would certainly > simplify matters. I experimented a while ago with packaging JACK for fink and I didn't get very far. I see a couple of options: - Going fully native. Using CoreAudio is not all that hard. That would lose the inter-application pluggability of Jack, though, and I'm not sure how important that is. - Biting the bullet & packaging JACK for fink. It sort of feels weird to me to install a systemwide server just to play Audio on an OS that is perfectly capable of playing Audio in the first place. - Running MIDI-only. I don't understand Rosegarden well enough yet to get a feeling for how important Audio is vs. MIDI, but my current instinct is to see it as primarily a MIDI based tool (especially on MacOS X, where a CoreMIDI client can feed into any other CoreMIDI client, and where GarageBand does an OK job for audio). - Detecting the presence or absence of JACK at runtime, so users have an option. > The MIDI parts of AlsaDriver are pretty substantial, and it might be > worth looking more closely at how MIDI setup is done in ArtsDriver > (currently non-working, but nonetheless fairly complete from the MIDI > perspective). aRts exposes a much simpler MIDI port concept to > Rosegarden than we use from ALSA, and the driver is correspondingly > much simpler Yes, one of the first preliminary activities I did was run "wc" on the two drivers :-) So from a user perspective, are the two drivers equally powerful, or is the ArtsDriver more limited? Matthias |
From: Chris C. <ca...@al...> - 2004-09-16 16:33:11
|
On Thursday 16 Sep 2004 16:55, Matthias Neeracher wrote: > - Going fully native. Using CoreAudio is not all that hard. That > would lose the inter-application pluggability of Jack, though, and > I'm not sure how important that is. I really can't comment on the relevance of JACK for an OS/X user. There is an article about it (JACK on OS/X I mean) in this month's Sound on Sound magazine, which presents it as an interesting system with some potential rather than an absolute must-have. To my mind the pluggability of JACK is a really dramatically impressive thing, but then the platform I use doesn't have so much commercial audio software ready to do impressive things without it. > - Running MIDI-only. I don't understand Rosegarden well enough yet > to get a feeling for how important Audio is vs. MIDI, but my > current instinct is to see it as primarily a MIDI based tool My personal feeling has always been that the most useful aspect of audio in Rosegarden is for synth plugins. I always thought the audio support we had was rather half-cocked before we managed to get synth plugins going. Obviously a MIDI-only version wouldn't be able to use those. > (especially on MacOS X, where a CoreMIDI client can feed into any > other CoreMIDI client Also true of ALSA on Linux, btw. > So from a user perspective, are the two drivers equally powerful, > or is the ArtsDriver more limited? The ArtsDriver is totally non-functional -- in fact it probably doesn't even compile -- so it's hard to compare. It has no support for plugins (the plugin host code itself is independent of driver type, but it still needs to be controlled through the driver), the audio sample playback code was never 100% complete, and I'm not sure recording of either audio or MIDI ever worked correctly. I might be maligning it though -- I think most of the basics were implemented one way or another. MIDI playback certainly used to work fine, but the timing code in AlsaDriver has been restructured a bit since then and it's possible the API might have changed sympathetically to it in a way that could break ArtsDriver. Chris |
From: Guillaume L. <gla...@te...> - 2004-09-16 21:29:00
|
On Thursday 16 September 2004 18:44, Chris Cannam wrote: > The ArtsDriver is totally non-functional -- in fact it probably > doesn't even compile Hasn't compiled since june 29th. I was thinking of suggesting that we get rid of it (again :-) ). Replacing it by an OS/X driver would be cool, actually. -- Guillaume. http://www.telegraph-road.org |
From: Silvan <dmm...@us...> - 2004-09-17 05:01:56
|
On Thursday 16 September 2004 12:44 pm, Chris Cannam wrote: > On Thursday 16 Sep 2004 16:55, Matthias Neeracher wrote: > > - Going fully native. Using CoreAudio is not all that hard. That > > would lose the inter-application pluggability of Jack, though, and > > I'm not sure how important that is. > the pluggability of JACK is a really dramatically impressive thing, > but then the platform I use doesn't have so much commercial audio > software ready to do impressive things without it. I couldn't have said that better. It really brings up a question of what role Rosegarden is to play on OS-X. If the idea is to bring a free alternative to all the very capable (and expensive) proprietary stuff that is already abundantly available, then it seems JACK, and with it, the host of satellite apps like Hydrogen, Ardour and friends might indeed be desirable enough to make it worth porting JACK. > > to get a feeling for how important Audio is vs. MIDI, but my > > current instinct is to see it as primarily a MIDI based tool > > My personal feeling has always been that the most useful aspect of > audio in Rosegarden is for synth plugins. I always thought the audio > support we had was rather half-cocked before we managed to get synth > plugins going. Obviously a MIDI-only version wouldn't be able to use > those. I had never heard of such a thing until you implemented that. (Of course the last sequencer I used was a win16 version of Cakewalk.) I look at audio in Rosegarden as being just usable and just flexible enough to allow me to do the kind of kind of thing I might have done with a four-track tape recorder in another era, except with rather more control. It isn't Ardour, and it's commensurately more approachable. When I first migrated to Linux, Ardour looked like the only choice I was going to have for this kind of work. It was very young then, just before JACK was invented, and just after. I had enormous difficulty compiling it, and even more difficulty trying to do anything with it. I've looked at it more recently, and I did manage to record something with it, finally, but I'm very glad to have Rosegarden as an alternative. These cool new synth plugin things are mere icing to me, although I might feel differently if I ever got the VST plugins working. (I never did hear back from you after that last round of trying to get it to go, I don't think.) Anyway, looking toward Macs, I think that Garage Band thing probably has the audio-for-dummies side licked, so that probably doesn't give Rosegarden much purpose in that area. To that extent, I'd agree with you that synth plugins would be the most important reason for Rosegarden to have audio on that platform. -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ http://rosegarden.sourceforge.net/tutorial/ |
From: Alexandre P. <ale...@gm...> - 2004-09-17 09:13:15
|
On Fri, 17 Sep 2004 01:01:48 -0400, Silvan <dmm...@us...> wrote: > On Thursday 16 September 2004 12:44 pm, Chris Cannam wrote: > > On Thursday 16 Sep 2004 16:55, Matthias Neeracher wrote: > > > > - Going fully native. Using CoreAudio is not all that hard. That > > > would lose the inter-application pluggability of Jack, though, and > > > I'm not sure how important that is. > > > the pluggability of JACK is a really dramatically impressive thing, > > but then the platform I use doesn't have so much commercial audio > > software ready to do impressive things without it. > > I couldn't have said that better. It really brings up a question of what role > Rosegarden is to play on OS-X. If the idea is to bring a free alternative to > all the very capable (and expensive) proprietary stuff that is already > abundantly available, then it seems JACK, and with it, the host of satellite > apps like Hydrogen, Ardour and friends might indeed be desirable enough to > make it worth porting JACK. With JACK from recent CVS you can do jackd -d coreaudio :-) Alexandre |
From: Chris C. <ca...@al...> - 2004-09-17 12:00:04
|
On Friday 17 Sep 2004 06:01, Silvan wrote: > worth porting JACK. I don't think it's even a question of porting JACK, as it definitely has a working OS/X CoreAudio port already. It may just be a packaging matter. > > My personal feeling has always been that the most useful aspect > > of audio in Rosegarden is for synth plugins. > > I had never heard of such a thing until you implemented that. Way back when I knew nothing at all about audio software (i.e. about two years ago), Richard did the first implementation of LADSPA effects plugins in Rosegarden. At the time I was quite unfamiliar with what an effects plugin did, and my first reaction on finding out was simple disappointment that there was no way to apply them to MIDI output. Without that, I hardly saw the point of LADSPA support in Rosegarden at all. Of course, the reason I knew nothing about effects plugins was related to the fact that I had no particular need for audio recording and playback, so it's not surprising that I saw it as next to useless. Richard, obviously, saw audio record/playback with plugins as a vital thing whose absence had been preventing him from using Rosegarden himself. > These cool new synth > plugin things are mere icing to me, although I might feel > differently if I ever got the VST plugins working. It's not VST vs non-VST so much as having a workable armoury of synths of any sort. There just aren't enough DSSI ones yet. A good drum synth (comparable to something like the freebie Drumatic VST) is number one on my personal wishlist. Chris |
From: Alexandre P. <ale...@gm...> - 2004-09-17 12:26:03
|
On Fri, 17 Sep 2004 13:11:10 +0100, Chris Cannam <ca...@al...> wrote: > Of course, the reason I knew nothing about effects plugins was related > to the fact that I had no particular need for audio recording and > playback, so it's not surprising that I saw it as next to useless. > Richard, obviously, saw audio record/playback with plugins as a vital > thing whose absence had been preventing him from using Rosegarden > himself. And not only him :) > > These cool new synth > > plugin things are mere icing to me, although I might feel > > differently if I ever got the VST plugins working. > > It's not VST vs non-VST so much as having a workable armoury of synths > of any sort. There just aren't enough DSSI ones yet. A good drum > synth (comparable to something like the freebie Drumatic VST) is > number one on my personal wishlist. Or rather NI BATTERY :-) Honestly, I was playing with xsynth yesterday. It's quite difficult to get any decent sound out of this proof-of-concept DSSI plug-in, but it's good that it exists. Actually, I was hoping that developers would be more interested in DSSI, but xsynth seems to be the only one for 2 months since the last DSSI release. So I'm a bit disappointed, but hey, I haven't lost my faith yet :) While I'm here, I didn't manage to start native Xsynth's GUI. I s'pose it should appear after clicking 'Editor' button, but it didn't work. I'm using Rosegarden 0.9.9, but soon will move to CVS. Alexandre |
From: Alexandre P. <ale...@gm...> - 2004-09-17 12:52:21
|
On Fri, 17 Sep 2004 13:11:10 +0100, Chris Cannam <ca...@al...> wrote: > A good drum > synth (comparable to something like the freebie Drumatic VST) is > number one on my personal wishlist. BTW, shoudln't it require a native drum editor in Rosegarden? Alexandre |
From: Silvan <dmm...@us...> - 2004-09-17 15:21:34
|
On Friday 17 September 2004 08:11 am, Chris Cannam wrote: > was simple disappointment that there was no way to apply them to MIDI > output. Without that, I hardly saw the point of LADSPA support in > Rosegarden at all. I saw immediate potential for that as a way to play with post-processing my recordings to try to make up for my absolutely dismal acoustic environment, but it took years before it ever worked well enough to use, and I finally had to sell out and trade system stability to pay the price for that. It's been an uneasy thing, and the irony is that I haven't actually used it for anything yet. I'm too busy to have time for a full blown multi-track, audio-intensive project anyway. > Of course, the reason I knew nothing about effects plugins was related > to the fact that I had no particular need for audio recording and > playback, so it's not surprising that I saw it as next to useless. And hey, don't get me wrong on the synth plugin front. It's icing to me, sure, but extremely tasty icing. It's one of the coolest things I've seen in years as far as the potential it has. It's just the realization so far has been pretty limited. > It's not VST vs non-VST so much as having a workable armoury of synths > of any sort. There just aren't enough DSSI ones yet. A good drum > synth (comparable to something like the freebie Drumatic VST) is > number one on my personal wishlist. I'll be happy to see a passle of DSSI plugins develop so I can push back or entirely avoid all those winey ones. I really should get that working at least far enough to reach a point where I can talk about it in more than a theoretical way though. -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ http://rosegarden.sourceforge.net/tutorial/ |
From: Chris C. <ca...@al...> - 2004-09-17 12:37:40
|
On Friday 17 Sep 2004 13:25, Alexandre Prokoudine wrote: > While I'm here, I didn't manage to start native Xsynth's GUI. I s'pose > it should appear after clicking 'Editor' button, but it didn't work. What version of liblo are you using? Some versions broke the DSSI GUI implementation. It should work with liblo-0.9. (I ought to update the Rosegarden configure script to test for that, probably.) Chris |
From: Alexandre P. <ale...@gm...> - 2004-09-17 12:46:08
|
On Fri, 17 Sep 2004 13:37:36 +0100, Chris Cannam <ca...@al...> wrote: > On Friday 17 Sep 2004 13:25, Alexandre Prokoudine wrote: > > While I'm here, I didn't manage to start native Xsynth's GUI. I s'pose > > it should appear after clicking 'Editor' button, but it didn't work. >=20 > What version of liblo are you using? Some versions broke the DSSI GUI > implementation. It should work with liblo-0.9. (I ought to update the > Rosegarden configure script to test for that, probably.) I'm not sure. RG 0.9.9 comes with liblo 0.8 from our RPM repository, but I remember myself compiling 0.9 from sources. I'll check, which of them is =D1=88=D1=82 =D0=B3=D1=8B=D1=83, as soon as I come home. Alexandre |
From: Alexandre P. <ale...@gm...> - 2004-09-19 17:18:22
|
On Fri, 17 Sep 2004 13:37:36 +0100, Chris Cannam <ca...@al...> wrote: > On Friday 17 Sep 2004 13:25, Alexandre Prokoudine wrote: > > While I'm here, I didn't manage to start native Xsynth's GUI. I s'pose > > it should appear after clicking 'Editor' button, but it didn't work. > > What version of liblo are you using? Some versions broke the DSSI GUI > implementation. It should work with liblo-0.9. (I ought to update the > Rosegarden configure script to test for that, probably.) Recompiled with liblo 0.9. The native gtk UI for Xsyhtn is loading now, but it looks messy -- some labels are placed between other. I can provide a screenshot, so that you don't have to guess what I'm talking about. Alexandre |
From: Chris C. <ca...@al...> - 2004-09-17 13:01:28
|
On Friday 17 Sep 2004 13:51, Alexandre Prokoudine wrote: > BTW, shoudln't it require a native drum editor in Rosegarden? Well, I wouldn't say "require". You can edit drums in the matrix editor, it's just not as nice. Chris |
From: Alexandre P. <ale...@gm...> - 2004-09-19 17:20:28
|
On Fri, 17 Sep 2004 14:01:26 +0100, Chris Cannam <ca...@al...> wrote: > On Friday 17 Sep 2004 13:51, Alexandre Prokoudine wrote: > > BTW, shoudln't it require a native drum editor in Rosegarden? > > Well, I wouldn't say "require". You can edit drums in the matrix editor, it's > just not as nice. Exactly. So is any of the core team developers personally interested in a native drum editor? Alexandre |
From: Chris C. <ca...@al...> - 2004-09-19 18:09:59
|
On Sunday 19 Sep 2004 18:18, Alexandre Prokoudine wrote: > The native gtk UI for Xsyhtn is loading > now, but it looks messy -- some labels are placed between other. I > can provide a screenshot, so that you don't have to guess what I'm > talking about. Please do, but it's probably better reported (or at least cc'd) to the dssi-devel list (also at lists.sourceforge.net). I had nothing to do with writing the Xsynth native GUI. Chris |
From: Alexandre P. <ale...@gm...> - 2004-09-19 21:19:40
Attachments:
xsynth-dssi-native.png
|
On Sun, 19 Sep 2004 19:21:06 +0100, Chris Cannam <ca...@al...> wrote: > On Sunday 19 Sep 2004 18:18, Alexandre Prokoudine wrote: > > The native gtk UI for Xsyhtn is loading > > now, but it looks messy -- some labels are placed between other. I > > can provide a screenshot, so that you don't have to guess what I'm > > talking about. > > Please do, but it's probably better reported (or at least cc'd) to the > dssi-devel list (also at lists.sourceforge.net). I had nothing to do > with writing the Xsynth native GUI. This was with QtCurve, I guess. But with Smooth Gorilla everything seems to be fine. Alexandre |
From: Silvan <dmm...@us...> - 2004-09-20 00:52:47
|
On Sunday 19 September 2004 01:20 pm, Alexandre Prokoudine wrote: > > Well, I wouldn't say "require". You can edit drums in the matrix editor, > > it's just not as nice. > > Exactly. So is any of the core team developers personally interested > in a native drum editor? We discussed this a bit back, trying to decide if it's worth it or not, with Hydrogen already a good drum editor, and with our ability to import Hydrogen patterns and... Whatever the thing that assembles the patterns into something is. Songs? I think we can import Hydrogen songs. I haven't actually checked into that yet, and it's a loose end I need to tie up. There was talk of a special drum clef, and of doing drum maps to map out keys to particular drums. There's all kinds of stuff we could do, and I'm mildly interested. I really don't use Hydrogen for much except making noise, and I'd rather do it with Rosegarden. Then again, I can hear Rich screaming about monolithic applications and redundant effort already. So I'd say the door is open a crack, but not very far. For my own part, I'm looking at wanting to improve mid-composition program changes, some key notation features (that NoteEdit has, and we don't), and better audio file management. That's about it for tall orders I can think of really. Rosegarden is pretty satisfactory to use already, and I did use the same buggy version of Cakewalk for 10 years. I'm quickly reaching a point where I'm not all that interested in trying to change things because what we've got is really pretty damn good. I think the core developers got there a long time ago. -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ http://rosegarden.sourceforge.net/tutorial/ |
From: Alexandre P. <ale...@gm...> - 2004-09-20 10:37:03
|
On Sun, 19 Sep 2004 20:52:39 -0400, Silvan <dmm...@us...> wrote: > On Sunday 19 September 2004 01:20 pm, Alexandre Prokoudine wrote: > > > > Well, I wouldn't say "require". You can edit drums in the matrix editor, > > > it's just not as nice. > > > > Exactly. So is any of the core team developers personally interested > > in a native drum editor? > > We discussed this a bit back, trying to decide if it's worth it or not, with > Hydrogen already a good drum editor, and with our ability to import Hydrogen > patterns and... Whatever the thing that assembles the patterns into > something is. Songs? I think we can import Hydrogen songs. I haven't > actually checked into that yet, and it's a loose end I need to tie up. Well, again. This is where the straightforward thing comes :) If you want to do your arrangement with drums/percussion fast, you need a native drum editor plus a DSSI drum machine. Export (from Hydrogen) and Import (to Hydrogen) add more steps, which a usual musician, who uses drums, would like to avoid. Yes, i did use JACK Transport -- it's rather a workaround in this case. > There was talk of a special drum clef, and of doing drum maps to map out keys > to particular drums. There's all kinds of stuff we could do, and I'm mildly > interested. I really don't use Hydrogen for much except making noise, and > I'd rather do it with Rosegarden. Then again, I can hear Rich screaming > about monolithic applications and redundant effort already. :) Ok, I got your point, thank you very much, Silvan. Things now get clearer ;-) > So I'd say the door is open a crack, but not very far. For my own part, I'm > looking at wanting to improve mid-composition program changes, some key > notation features (that NoteEdit has, and we don't), and better audio file > management. I remember someone here trying to put his hands on audio stuff -- like a simple wav editor etc. Errm, hello? :) Alexandre |
From: Silvan <dmm...@us...> - 2004-09-21 05:38:44
|
> want to do your arrangement with drums/percussion fast, you need a > native drum editor plus a DSSI drum machine. Export (from Hydrogen) > and Import (to Hydrogen) add more steps, which a usual musician, who > uses drums, would like to avoid. That's an interesting idea. The DSSI drum machine I mean. Anyway, for my part, the procedure I outlined in my tutorial really isn't all that terrible to do, really. I never actually use Hydrogen for anything anyway. It could be easier having some kind of ABBA pattern tracker flummy built in, but we don't really need it. Just make the A and B bits segments and copy/repeat them around as necessary. Not quite as elegant as Hydrogen, but a lot easier than this used to be with my ancient Cakewalk, which was good enough for me for 10 years. Then again, I suck at sequencing drums anyway. About all I'd halfway like to see is some kind of thing to label what drums the keys on the keyboard are supposed to be. Some new kind of special program bank that could map onto the matrix view under whatever useful circumstances. (Track routed to drum instrument, some manual checkbox toggled, whatever.) > Yes, i did use JACK Transport -- it's rather a workaround in this case. I've tried doing that, and I'd rather import the patterns. I found life was pretty screwy with the JACK transport enabled, and I haven't repeated that particular experiment lately. -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ http://rosegarden.sourceforge.net/tutorial/ |
From: Richard B. <ric...@fe...> - 2004-09-22 06:41:43
|
On Tuesday 21 September 2004 06:38, Silvan wrote: > That's an interesting idea. The DSSI drum machine I mean. You can of couse use Hydrogen as a Rosegarden MIDI client through the ALSA MIDI mechanism. And adding the missing link (double clicking on a "drum" segment and opening it in Hyrdogen) might be something worth thinking about. However clunky. B |