rosegarden-devel — Rosegarden development
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(138) |
Nov
(254) |
Dec
(246) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(543) |
Feb
(315) |
Mar
(531) |
Apr
(512) |
May
(327) |
Jun
(314) |
Jul
(511) |
Aug
(623) |
Sep
(232) |
Oct
(408) |
Nov
(285) |
Dec
(309) |
| 2003 |
Jan
(594) |
Feb
(532) |
Mar
(548) |
Apr
(535) |
May
(415) |
Jun
(490) |
Jul
(320) |
Aug
(117) |
Sep
(214) |
Oct
(349) |
Nov
(310) |
Dec
(354) |
| 2004 |
Jan
(310) |
Feb
(203) |
Mar
(480) |
Apr
(632) |
May
(477) |
Jun
(369) |
Jul
(362) |
Aug
(226) |
Sep
(170) |
Oct
(235) |
Nov
(149) |
Dec
(108) |
| 2005 |
Jan
(40) |
Feb
(372) |
Mar
(72) |
Apr
(46) |
May
(288) |
Jun
(205) |
Jul
(279) |
Aug
(184) |
Sep
(52) |
Oct
(139) |
Nov
(180) |
Dec
(199) |
| 2006 |
Jan
(172) |
Feb
(261) |
Mar
(275) |
Apr
(85) |
May
(86) |
Jun
(300) |
Jul
(216) |
Aug
(121) |
Sep
(148) |
Oct
(30) |
Nov
(141) |
Dec
(98) |
| 2007 |
Jan
(68) |
Feb
(85) |
Mar
(113) |
Apr
(73) |
May
(24) |
Jun
(114) |
Jul
(132) |
Aug
(76) |
Sep
(100) |
Oct
(137) |
Nov
(85) |
Dec
(98) |
| 2008 |
Jan
(48) |
Feb
(78) |
Mar
(47) |
Apr
(164) |
May
(58) |
Jun
(26) |
Jul
(154) |
Aug
(110) |
Sep
(310) |
Oct
(128) |
Nov
(84) |
Dec
(27) |
| 2009 |
Jan
(361) |
Feb
(134) |
Mar
(123) |
Apr
(107) |
May
(51) |
Jun
(107) |
Jul
(232) |
Aug
(359) |
Sep
(266) |
Oct
(150) |
Nov
(172) |
Dec
(86) |
| 2010 |
Jan
(189) |
Feb
(144) |
Mar
(21) |
Apr
(47) |
May
(112) |
Jun
(33) |
Jul
(10) |
Aug
(67) |
Sep
(97) |
Oct
(80) |
Nov
(78) |
Dec
(29) |
| 2011 |
Jan
(25) |
Feb
(109) |
Mar
(27) |
Apr
(43) |
May
(14) |
Jun
(23) |
Jul
(19) |
Aug
(12) |
Sep
(118) |
Oct
(77) |
Nov
(52) |
Dec
(38) |
| 2012 |
Jan
(70) |
Feb
(84) |
Mar
(38) |
Apr
(74) |
May
(63) |
Jun
(47) |
Jul
(9) |
Aug
(16) |
Sep
(151) |
Oct
(64) |
Nov
(54) |
Dec
(24) |
| 2013 |
Jan
(53) |
Feb
(62) |
Mar
(52) |
Apr
(51) |
May
(48) |
Jun
(28) |
Jul
(82) |
Aug
(28) |
Sep
(97) |
Oct
(51) |
Nov
(52) |
Dec
(14) |
| 2014 |
Jan
(2) |
Feb
(9) |
Mar
(20) |
Apr
(22) |
May
(81) |
Jun
(22) |
Jul
(7) |
Aug
(8) |
Sep
(9) |
Oct
(9) |
Nov
(18) |
Dec
(10) |
| 2015 |
Jan
(6) |
Feb
(6) |
Mar
(20) |
Apr
(47) |
May
(9) |
Jun
(20) |
Jul
|
Aug
(5) |
Sep
(36) |
Oct
(37) |
Nov
(163) |
Dec
(40) |
| 2016 |
Jan
(13) |
Feb
(28) |
Mar
(5) |
Apr
(13) |
May
(7) |
Jun
(28) |
Jul
(27) |
Aug
(2) |
Sep
(15) |
Oct
(9) |
Nov
(7) |
Dec
(27) |
| 2017 |
Jan
(25) |
Feb
(37) |
Mar
(18) |
Apr
(9) |
May
|
Jun
(4) |
Jul
|
Aug
(5) |
Sep
|
Oct
(2) |
Nov
(8) |
Dec
(5) |
| 2018 |
Jan
|
Feb
(8) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(19) |
2
(11) |
3
(8) |
4
(1) |
5
(10) |
|
6
(19) |
7
(8) |
8
(9) |
9
(4) |
10
(18) |
11
(16) |
12
(1) |
|
13
(12) |
14
(2) |
15
(8) |
16
(5) |
17
(10) |
18
(14) |
19
(1) |
|
20
(2) |
21
(15) |
22
(16) |
23
(29) |
24
(7) |
25
(19) |
26
(11) |
|
27
(14) |
28
(2) |
29
(3) |
30
(15) |
31
(11) |
|
|
|
From: Guillaume Laurent <glaurent@te...> - 2003-07-30 20:28:36
|
On Wednesday 30 July 2003 11:01, Richard Bown wrote: > > I'm going to buy you a post it note - "Program Changes are not > Instruments!" Or next time you do t-shirts, have this printed on one of them and send it to me :-). Well you have to admit that's pretty crappy terminology. I know we inherit it from MIDI and can't do much about it, but honestly, a "Cello" does not make me think of "Program Change". -- Guillaume. http://www.telegraph-road.org |
|
From: Chris Cannam <cannam@al...> - 2003-07-30 18:26:05
|
On Wednesday 30 July 2003 01:35, Silvan wrote: > On Monday 28 July 2003 08:24 am, Chris Cannam wrote: > > Richard Bown wrote: > > > Can you or someone add these to the 1.0_release.txt then please? > > > > Ingenious suggestion. > > I've been thinking about that for awhile... What do you have in mind > for that class of performance directions (segnos, codas, etc.)? It > seems to me that making them actually work would be ugly to say the > least. Yes, it's a surprisingly difficult problem even for the simple repeats. I think the only thing we can rely on doing without confusion is to=20 default to showing repeats on barlines that end segments that are set=20 as repeating. I'm not sure whether we can even reliably do the reverse=20 (that is, mark a segment as repeating in the main view if someone sets=20 a repeating barline at the end of it). We possibly can, but there=20 still various problems with both of these: for example, the only way to=20 have a repeating segment without playing the repeat is to place another=20 segment immediately after it, and that gives you no way to quickly=20 switch repeats on and off. =46rom the notation point of view, it almost makes more sense to store=20 repeats and segnos/codas/1-2-endings globally like time signature=20 changes, rather than in individual segments. Possibly. I don't much=20 like that though for other reasons (introducing a global "control flow"=20 mechanism is a complicated enough idea without then artificially=20 limiting it by basing it on what happens to work well in classical=20 notation). > I was thinking you might decide to implement static events > that show up as window dressing, but which don't actually alter > playback. That seems wrong, yet pragmatic. I think for segno at least we should certainly do that first. The other thing I mentally place in the same category as these is=20 bracketed/joined staffs (e.g. for piano etc). Again, these are things=20 that suggest something about the structure of your track/instrument=20 arrangement besides just graphics. Chris |
|
From: Silvan <dmmcintyr@us...> - 2003-07-30 14:31:40
|
On Wednesday 30 July 2003 05:00 am, Guillaume Laurent wrote: > On Wednesday 30 July 2003 09:08, John OHagan wrote: > > #8 0x40fd5f1a in snd_seq_query_next_client () from > > /usr/lib/libasound.so.2 > > We seem to get quite a few of these. Alexandre was reporting one recently > too. It's most probably an Alsa issue... For the OP's info, I'm running kernel 2.4.20 (Debian source, self-compiled) and ALSA 0.9.3c. The ALSA source was installed as a Debian (testing) package a bit back. I notice there's new source for 0.9.4 that I got as part of some update or other, but I have never compiled it. My ALSA utils are 0.9.4, but my libs are definitely still 0.9.3c. Everything works perfectly well. Maybe there's some problem with 0.9.4 libs and Rosegarden due to an API change or something. Just a thought. -- Michael McIntyre ---- Silvan <dmmcintyr@...> Linux fanatic, and certified Geek; registered Linux user #243621 Confirmed post number: 16839 Approximate word count: 505170 http://www.geocities.com/Paris/Rue/5407/ |
|
From: Richard Bown <bownie@bo...> - 2003-07-30 09:06:09
|
On Wednesday 30 July 2003 9:59 am, Guillaume Laurent wrote: > > Still not quite sure what you meant about changing instruments > > though? Did you mean program changes? > > Yes (e.g. from "Accoustic Grand Piano" to "Cello"). Ah ok, fine then. Those are just async MIDI events sent direct from the GUI then. I'm going to buy you a post it note - "Program Changes are not Instruments!" R |
|
From: Guillaume Laurent <glaurent@te...> - 2003-07-30 09:01:04
|
On Wednesday 30 July 2003 09:08, John OHagan wrote: > #8 0x40fd5f1a in snd_seq_query_next_client () from /usr/lib/libasound.so.2 We seem to get quite a few of these. Alexandre was reporting one recently too. It's most probably an Alsa issue... -- Guillaume. http://www.telegraph-road.org |
|
From: Guillaume Laurent <glaurent@te...> - 2003-07-30 08:59:43
|
On Wednesday 30 July 2003 10:41, Richard Bown wrote: > > Ok, well let us know and _do_ label this otherwise it could get > interesting! But yeah, that seems like a sensible way of doing things. Will do. > Still not quite sure what you meant about changing instruments though? Did > you mean program changes? Yes (e.g. from "Accoustic Grand Piano" to "Cello"). -- Guillaume. http://www.telegraph-road.org |
|
From: Richard Bown <bownie@bo...> - 2003-07-30 08:46:15
|
On Wednesday 30 July 2003 9:39 am, Guillaume Laurent wrote: > OK, so that's where the ControlBlock comes in. The MappedEvent's > InstrumentId is now a TrackId (I haven't changed the types yet), and > all needed track info is found with that Id on the ControlBlock. Ok, well let us know and _do_ label this otherwise it could get interesting! But yeah, that seems like a sensible way of doing things. Still not quite sure what you meant about changing instruments though? Did you mean program changes? R |
|
From: Guillaume Laurent <glaurent@te...> - 2003-07-30 08:43:16
|
On Wednesday 30 July 2003 09:48, Chris Cannam wrote: > > The problem with changing the instrument from the dropdown is that each > MappedEvent already has an instrument id fixed into it. So if you > change the instrument for a track, you surely need to rewrite all the > MappedEvents for all the segments on that track with the new instrument > ids in them. As I notice Bownie has also just said, I'd be surprised > if it worked without doing that. Well currently the only thing that happens is the sending of a MidiControllerEvent. The segments are not refreshed. The purpose of the ControlBlock is (among other things) to avoid that large refresh. Next thing I'd put it would be a track's muted status. > The other thing is, if you store the track id -> instrument id table in > a control block and make that available to the sequencer, what does > that actually give you? The sequencer doesn't know which track a > segment or MappedEvent is on anyway... does it? Yes, it does, because I pass the TrackId instead of the InstrumentId to the MappedEvent's ctor (that part is currently commented out). -- Guillaume. http://www.telegraph-road.org |
|
From: Guillaume Laurent <glaurent@te...> - 2003-07-30 08:39:24
|
On Wednesday 30 July 2003 09:57, Richard Bown wrote: > No, the sequencer currently has no notion of tracks. But I think we now > need to introduce that layer - the current MappedInstrument layer was > put in just for simplicity to begin with and to get something working for > the slice-based approach (where the MappedEvents would be updated regularly > with new Instrument information on each fetch). We now need more > description of this mapping at the sequencer. OK, so that's where the ControlBlock comes in. The MappedEvent's InstrumentId is now a TrackId (I haven't changed the types yet), and all needed track info is found with that Id on the ControlBlock. -- Guillaume. http://www.telegraph-road.org |
|
From: Richard Bown <bownie@bo...> - 2003-07-30 08:02:14
|
On Wednesday 30 July 2003 8:48 am, Chris Cannam wrote: > For the sequencer's purposes it really just describes which MIDI > channel of a particular device a track is playing on. At the GUI > side we associate all sorts of information with an instrument > (volume, pan, program changes etc), but the sequencer doesn't know > that -- it just gets asynchronous events when they change, which it > pushes out to the MIDI device on the right channel for the event's > instrument. Yeah, but the thing is it probably should know about all this stuff now. In other words we probably do want Instrument/Track information at the Sequencer now so that we can firstly solve this issue but also provide information for the Studio as we improve its facilities. > The sequencer doesn't know which track > a segment or MappedEvent is on anyway... does it? No, the sequencer currently has no notion of tracks. But I think we now need to introduce that layer - the current MappedInstrument layer was put in just for simplicity to begin with and to get something working for the slice-based approach (where the MappedEvents would be updated regularly with new Instrument information on each fetch). We now need more description of this mapping at the sequencer. R |
|
From: Chris Cannam <cannam@al...> - 2003-07-30 07:48:39
|
On Wednesday 30 July 2003 00:54, Guillaume Laurent wrote: > On Wednesday 30 July 2003 01:05, Guillaume Laurent wrote: > > And I actually don't know how, apparently it's not done by > > refreshing the whole segment. > > OK, we're sending a MidiController event... I guess I'm being > confused again by what instrument IDs actually represent. For the sequencer's purposes it really just describes which MIDI channel of a particular device a track is playing on. At the GUI side we associate all sorts of information with an instrument (volume, pan, program changes etc), but the sequencer doesn't know that -- it just gets asynchronous events when they change, which it pushes out to the MIDI device on the right channel for the event's instrument. The problem with changing the instrument from the dropdown is that each MappedEvent already has an instrument id fixed into it. So if you change the instrument for a track, you surely need to rewrite all the MappedEvents for all the segments on that track with the new instrument ids in them. As I notice Bownie has also just said, I'd be surprised if it worked without doing that. The other thing is, if you store the track id -> instrument id table in a control block and make that available to the sequencer, what does that actually give you? The sequencer doesn't know which track a segment or MappedEvent is on anyway... does it? Chris |
|
From: Richard Bown <bownie@bo...> - 2003-07-30 07:26:32
|
On Wednesday 30 July 2003 8:17 am, Richard Bown wrote: > I've not looked at the mmap stuff BTW I'm really hoping to "get stuck in" sometime soon but it's madness at the moment and I'm on hols in two and half weeks time and really looking forward to it. Still aiming to get some serious work done on RG before then to push it on but I'm waiting for the right wave to come along.. R |
|
From: Richard Bown <bownie@bo...> - 2003-07-30 07:22:10
|
On Wednesday 30 July 2003 12:54 am, Guillaume Laurent wrote: > OK, we're sending a MidiController event... I guess I'm being > confused again by what instrument IDs actually represent. *sigh* Ok, we have a set of Segments which map to Track Ids. Then we have a Track that maps to an Instrument. Instrument IDs are generated according to Devices (MidiDevices or AudioDevices) and have associated channels, pan levels, controllers etc. When Segments are turned into MappedEvents they retain InstrumentId but if you read the top of sound/MappedEvent.h: [..] // The MappedEvent/Instrument relationship is interesting - we don't // want to duplicate the entire Instrument at the Sequencer level as // it'd be messy and unnecessary. Instead we use a MappedInstrument // which is just a very cut down Sequencer-side version of an Instrument. [..] Slightly out of date now but still relevant enough to be useful. I've not looked at the mmap stuff still but it's basically the MappedComposition yes? It will therefore hold MappedEvents that have InstrumentIds in them. I would assume that the Segments are getting remapped in that case (or at least something is changing the InstrumentIds at the MappedEvent level) if you're getting new instruments when modifying them. Are you actually talking about changing Instruments or changing the program changes (in the IPB drop down)? The Program Changes and Bank Changes are just asynchronous MIDI events, yes. If you're remapping Instruments and not regenerating the MappedComposition I'd be surprised if it works. R |
|
From: John OHagan <jaygon2000@bi...> - 2003-07-30 07:10:45
|
Package: rosegarden Version: 0.9.1 (KDE 3.1.2) ( (testing/unstable)) Severity: grave Compiler: gcc version 3.3 (Debian) OS: Linux 2.4.21-pre7-ac1 i686 ( (testing/unstable)) Here is the backtrace on this; please let me know if there is a fix because I love this program! (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...[New Thread 16384 (LWP 4342)] (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... 0x4110bb89 in wait4 () from /lib/libc.so.6 #0 0x4110bb89 in wait4 () from /lib/libc.so.6 #1 0x4117f000 in sys_sigabbrev () from /lib/libc.so.6 #2 0x40ffe061 in waitpid () from /lib/libpthread.so.0 #3 0x406b1348 in KCrash::defaultCrashHandler(int) () from /usr/lib/libkdecore.so.4 #4 0x410989d8 in sigaction () from /lib/libc.so.6 #5 0x40ffc521 in raise () from /lib/libpthread.so.0 #6 0x41099986 in abort () from /lib/libc.so.6 #7 0x41092ae9 in __assert_fail () from /lib/libc.so.6 #8 0x40fd5f1a in snd_seq_query_next_client () from /usr/lib/libasound.so.2 #9 0x4006e6a1 in Rosegarden::AlsaDriver::checkForNewClients() () from /usr/lib/libRosegardenSequencer.so.0 #10 0x0805d52d in Rosegarden::Controller::~Controller() () #11 0x080629c1 in QAsciiDict<int>::deleteItem(void*) () #12 0x409fa132 in QObject::activate_signal(QConnectionList*, QUObject*) () from /usr/lib/libqt-mt.so.3 #13 0x409f9fef in QObject::activate_signal(int) () from /usr/lib/libqt-mt.so.3 #14 0x40c63968 in QTimer::timeout() () from /usr/lib/libqt-mt.so.3 #15 0x40a164bf in QTimer::event(QEvent*) () from /usr/lib/libqt-mt.so.3 #16 0x409a61be in QApplication::internalNotify(QObject*, QEvent*) () from /usr/lib/libqt-mt.so.3 #17 0x409a5dff in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libqt-mt.so.3 #18 0x4064e84b in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdecore.so.4 #19 0x4098442b in QEventLoop::activateTimers() () from /usr/lib/libqt-mt.so.3 #20 0x409653a9 in QEventLoop::processEvents(unsigned) () from /usr/lib/libqt-mt.so.3 #21 0x409b7806 in QEventLoop::processEvents(unsigned, int) () from /usr/lib/libqt-mt.so.3 #22 0x409a6306 in QApplication::processEvents(int) () from /usr/lib/libqt-mt.so.3 #23 0x0805edc4 in std::_Rb_tree_rotate_right(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*&) () #24 0x41087a51 in __libc_start_main () from /lib/libc.so.6 |
|
From: Silvan <dmmcintyr@us...> - 2003-07-30 00:35:25
|
On Monday 28 July 2003 08:24 am, Chris Cannam wrote: > Richard Bown wrote: > > Can you or someone add these to the 1.0_release.txt then please? > > Ingenious suggestion. I've been thinking about that for awhile... What do you have in mind for that class of performance directions (segnos, codas, etc.)? It seems to me that making them actually work would be ugly to say the least. I was thinking you might decide to implement static events that show up as window dressing, but which don't actually alter playback. That seems wrong, yet pragmatic. At least they could be printed/exported. -- Michael McIntyre ---- Silvan <dmmcintyr@...> Linux fanatic, and certified Geek; registered Linux user #243621 Confirmed post number: 16821 Approximate word count: 504630 http://www.geocities.com/Paris/Rue/5407/ |