From: John S. <js...@ca...> - 2007-04-19 04:34:25
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7651.59"> <TITLE>Processing of MMC messages from external keyboard besides 'Play' = and 'Stop'</TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <P><FONT SIZE=3D2>Dear Gardeners,<BR> <BR> I am just starting to use Rosegarden on Linux with an Axiom USB = keyboard. I configured the keyboard controls to play, record, = stop, rewind, etc., but only the play and stop controls seemed to = work.<BR> <BR> Looking at the source, it seems only the play and stop commands are = currently supported. For my application, I would particularly like = to be able to 'record' as well (and the remaining controls would be = handy). I note that the MMC commands actually seem to relate = (exclusively?) to punch-in (which I assume is kicking into record mode = when something is already playing). I'm happy just to have it = start as though 'record' were pressed on the transport control in the = gui.<BR> <BR> Question: Is there a particular architectural or other reason why the = other MMC commands should not be supported?<BR> <BR> Sorry for asking what may be an obvious question, but it looked like it = might be easy to do (e.g. something I could do), which immediately leads = me to suspect that if it's not already there then there may be a good = reason for it. Thanks for any pointers...<BR> <BR> John</FONT> </P> </BODY> </HTML> |
From: Pedro Lopez-C. <ped...@gm...> - 2007-04-22 17:52:00
|
Hi John, I think that nobody has answered your email yet. Sorry about that. But plea= se,=20 don't send more HTML messages to the list. We expect plain text only. If yo= u=20 don't do so, your message may be filtered out as spam, or ignored. On Thursday, 19 April 2007 06:33, John Sinton wrote: > Dear Gardeners, > > I am just starting to use Rosegarden on Linux with an Axiom USB keyboard= =2E=A0 > I configured the keyboard controls to play, record, stop, rewind, etc., b= ut > only the play and stop controls seemed to work. > > Looking at the source, it seems only the play and stop commands are > currently supported.=A0 For my application, I would particularly like to = be > able to 'record' as well (and the remaining controls would be handy).=A0 I > note that the MMC commands actually seem to relate (exclusively?) to > punch-in (which I assume is kicking into record mode when something is > already playing).=A0 I'm happy just to have it start as though 'record' w= ere > pressed on the transport control in the gui. > > Question: Is there a particular architectural or other reason why the > other MMC commands should not be supported? > > Sorry for asking what may be an obvious question, but it looked like it > might be easy to do (e.g. something I could do), which immediately leads = me > to suspect that if it's not already there then there may be a good reason > for it.=A0 Thanks for any pointers... > > John About the missing MMC commands: I would like to see it implemented too. We= =20 would be thankful if you provide a patch.=20 Please look at our code guideliness: http://rosegarden.svn.sourceforge.net/viewvc/*checkout*/rosegarden/trunk/do= cs/code/guidelines.txt Technical background for this issue. In AlsaDriver::testForMMCSysex() you n= eed=20 to call ExternalTransport::transportChange() and transportJump() for the=20 missing MMC functions, defined in sound/Midi.h=20 ExternalTransport is an interface, implemented by RosegardenSequencerApp. I= f=20 you look at RosegardenSequencerApp::checkExternalTransport(), you will see= =20 that there is already some support for additional functions. Please, ask to the list if you have any doubt. Regards, Pedro |
From: Guillaume L. <gla...@te...> - 2007-04-23 18:45:47
|
On Sunday 22 April 2007, Pedro Lopez-Cabanillas wrote: > But please, > don't send more HTML messages to the list. We expect plain text only. If > you don't do so, your message may be filtered out as spam, or ignored. Not really, sforge will accept it fine (there are no real spam filters on sforge anyway, beyond very basic regexp-based blacklisting), and from a user standpoint, so will I. I used to hate HTML mail as well, until I realised that all these silly typographic conventions we use for quoting, making words *stand out*, etc... are just some dumbed down, inefficient markup. Might as well use a more efficient, standard one. -- Guillaume. http://telegraph-road.org |
From: Vince N. <vin...@gm...> - 2007-04-23 10:38:00
|
This topic came up a while ago, didn''t it? Please bear my comment at that time in mind: "is there a risk that (when using RG in conjuction with an external recorder) RG always goes into record mode when you record on the external recorder? You want start/stop/position to be in lockstep but not necessarily all-or-nothing record. (That is, it makes perfect sense for the external recorder to be recording live instruments while RG is merely playing along in sync, not recording.)" Vince On 22/04/07, Pedro Lopez-Cabanillas <ped...@gm...> wrote: > Hi John, > > I think that nobody has answered your email yet. Sorry about that. But please, > don't send more HTML messages to the list. We expect plain text only. If you > don't do so, your message may be filtered out as spam, or ignored. > > On Thursday, 19 April 2007 06:33, John Sinton wrote: > > Dear Gardeners, > > > > I am just starting to use Rosegarden on Linux with an Axiom USB keyboard. > > I configured the keyboard controls to play, record, stop, rewind, etc., but > > only the play and stop controls seemed to work. > > > > Looking at the source, it seems only the play and stop commands are > > currently supported. For my application, I would particularly like to be > > able to 'record' as well (and the remaining controls would be handy). I > > note that the MMC commands actually seem to relate (exclusively?) to > > punch-in (which I assume is kicking into record mode when something is > > already playing). I'm happy just to have it start as though 'record' were > > pressed on the transport control in the gui. > > > > Question: Is there a particular architectural or other reason why the > > other MMC commands should not be supported? > > > > Sorry for asking what may be an obvious question, but it looked like it > > might be easy to do (e.g. something I could do), which immediately leads me > > to suspect that if it's not already there then there may be a good reason > > for it. Thanks for any pointers... > > > > John > > About the missing MMC commands: I would like to see it implemented too. We > would be thankful if you provide a patch. > > Please look at our code guideliness: > http://rosegarden.svn.sourceforge.net/viewvc/*checkout*/rosegarden/trunk/docs/code/guidelines.txt > > Technical background for this issue. In AlsaDriver::testForMMCSysex() you need > to call ExternalTransport::transportChange() and transportJump() for the > missing MMC functions, defined in sound/Midi.h > > ExternalTransport is an interface, implemented by RosegardenSequencerApp. If > you look at RosegardenSequencerApp::checkExternalTransport(), you will see > that there is already some support for additional functions. > > Please, ask to the list if you have any doubt. > > Regards, > Pedro > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Rosegarden-devel mailing list > Ros...@li... - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel > |
From: Pedro Lopez-C. <ped...@gm...> - 2007-04-23 21:43:29
|
On Monday, 23 April 2007 12:37, Vince Negri wrote: > "is there a risk that (when using RG > in conjuction with > an external recorder) RG always goes into record mode when you record > on the external > recorder? You want start/stop/position to be in lockstep > but not necessarily all-or-nothing record. (That is, it makes perfect > sense for the external recorder to be recording live instruments while > RG is merely playing along in sync, not recording.)" Your point is a legitimate one. We need to address this scenario, and I think that we centainly can. With a bit of work. We needed to extend the current implementation, adding support for the MMC channel (or ID) mechanism. See references 1, 2 and 3. Every device sending/responding to MIDI Machine Control messages may have an unique ID number in the MIDI network. The MMC slaves only recognize the MMC commands matching their own ID, or equal to the broadcast ID (0x7f). It is possible to have two (or more) devices set to the same ID number. What this means is that both devices always respond to the same MIDI Machine Control messages with that ID number. There is no limit as to how many individual ID numbers a given device can respond to (there are 126 channels). We need to include in Rosegarden a configuration option to allow the user to specify an ID for send and receive MMC commands. To give complete flexibility, we should allow for each master MMC command a different ID, including the option to send the bradcast ID. Idem for receiving commands: allow the user to specify a different ID for each command, with the option to recognize or not the broadcast ID. To summarise: Master Slave MMC Command common id=?? common id=?? ------------------------------+-------------+------------------+ 0x01 Stop id=?? id=?? / bcast[y/n] 0x02 Play id=?? id=?? / bcast[y/n] 0x03 Deferred Play id=?? id=?? / bcast[y/n] 0x04 Fast Forward id=?? id=?? / bcast[y/n] 0x05 Rewind id=?? id=?? / bcast[y/n] 0x06 Record Strobe (Punch In) id=?? id=?? / bcast[y/n] 0x07 Record Exit (Punch out) id=?? id=?? / bcast[y/n] 0x09 Pause id=?? id=?? / bcast[y/n] References [1] http://www.borg.com/~jglatt/tech/mmc.htm [2] http://en.wikipedia.org/wiki/MIDI_Machine_Control [3] http://www.midi.org/about-midi/specshome.shtml Regards, Pedro |
From: Anders D. <an...@da...> - 2007-04-23 12:28:36
|
On 4/23/07, Vince Negri <vin...@gm...> wrote: > > This topic came up a while ago, didn''t it? Please bear my comment at > that time in mind: > > "is there a risk that (when using RG > in conjuction with > an external recorder) RG always goes into record mode when you record > on the external > recorder? You want start/stop/position to be in lockstep > but not necessarily all-or-nothing record. (That is, it makes perfect > sense for the external recorder to be recording live instruments while > RG is merely playing along in sync, not recording.)" > > Hi everybody, I'm currently setting up a home studio with a Korg D12 recorder and Rosegarden for sequencing of MIDI instrument. In the process I reckon Rosegardens MMC-support to be slightly flaky. First some background on my setup: * I have Rosegarden setup as MMC master and the Korg D12 as slave. This means I will use Rosegarden for all transport operations, play/stop/pause/locate/record, the D12 slave should just follow its master. Whatever operations is done in with the MMC master transport should be mimicked by the MMC slave. Historic background: MMC (Master Machine Control) is really just a remote controlled transport protocol, the intention was to make it possible to control an analog multi-track recorder or ADAT from within the sequencer or controlling the sequencer via the recorders transport panel. * The Korg D12 is setup as the MTC master and Rosegarden as the slave. So once the recorder start to roll it will output time code the sequencer should sync to. Historic background: Note that the MMC protocol above only solves the remote control problem and has nothing to do with keeping stuff in sync. In fact, there's no guarantee that the recorder will start playback or record immediately after receiving a MMC command, it's very likely it will need to stretch the tape and pre-roll before doing anything. To solve this problem SMPTE time code used to be striped on the outermost track and MIDI interfaces was fitted with special SMPTE jacks that could decode the signal so the sequencer could get in sync (this also solves the problem with analog machines varying their speed). MTC is just the pure MIDI version of the SMPTE solution. So what I would expect from this kind of setup is to remotely control the transport of the recorder completely from the sequencer, the former simply mimicking the later, and once the recorder start to roll, the sequencer will sync to it. That mean I would like to be able to hit "record" in Rosegarden (when acting as MMC master) even if no tracks are armed in the sequencer, because they may be armed on the recorder. Currently I have to press play in Rosegarden and then manually punch-in on the recorder. Now to the flaky bit. While "play", "stop" and "location" works fine, hitting record in Rosegarden to record MIDI tracks does not. Rosegardens behavior then becomes slightly antsy. Whenever I hit play the location will start to jump all over the place until finally stopping three seconds into the song (if I remember the time correctly). To get rid of the behavior I need to restart Rosegarden altogether. -- Anders Dahnielson <an...@da...> |
From: Anders D. <an...@da...> - 2007-04-23 17:59:47
|
On 4/23/07, Anders Dahnielson <an...@da...> wrote: > > > Now to the flaky bit. While "play", "stop" and "location" works fine, > hitting record in Rosegarden to record MIDI tracks does not. Rosegardens > behavior then becomes slightly antsy. Whenever I hit play the location will > start to jump all over the place until finally stopping three seconds into > the song (if I remember the time correctly). To get rid of the behavior I > need to restart Rosegarden altogether. > > I should probably add that I'm using the 1.5 stable subversion branch of Rosegarden. I will recompile to get debug info and try digging into what may cause the strange behavior. -- Anders Dahnielson <an...@da...> |
From: Arnout E. <ros...@bz...> - 2007-04-23 21:00:54
|
Guillaume Laurent wrote: > I used to hate HTML mail as well, until I realised that all these > silly typographic conventions we use for quoting, making words *stand > out*, etc... are just some dumbed down, inefficient markup. Might as > well use a more efficient, standard one. Offtopic, but anyway: luckily, there's "Mime: multipart/alternatives": this mechanism, supported by most mailers, allow an email to contain both an HTML and a plaintext (and in theory, for example, a PDF for printing) version of the email. The receiver's mail client can choose which alternative to show. I'm certainly not against HTML email, but I do think people should be encouraged to configure their mailers to also send the plaintext alternative (for example: I usually use thunderbird, in which I view HTML email in full glory, but sometimes I like to use mutt, which is when the plaintext alternatives come in handy). Arnout |
From: Chris C. <ca...@al...> - 2007-04-23 21:13:15
|
On Monday 23 April 2007 21:59, Arnout Engelen wrote: > I'm certainly not against HTML email, but I do think people should be > encouraged to configure their mailers to also send the plaintext alternative I have some systems set up to delete HTML-only email automatically, because hardly any real mail clients send it -- most use multipart/alternative -- so it's a pretty good indicator of spam. SpamAssassin has a rule to do the same, although not everyone uses it. So I agree, it's a bad idea to send HTML mail without a plain text alternative. Chris |
From: Guillaume L. <gla...@te...> - 2007-04-24 14:53:35
|
On Apr 23, 2007, at 11:11 PM, Chris Cannam wrote: > > So I agree, it's a bad idea to send HTML mail without a plain text > alternative. Yes, I had the case with the text alternative in mind. -- Guillaume http://telegraph-road.org |
From: Chris C. <ca...@al...> - 2007-04-23 21:18:30
|
On Monday 23 April 2007 13:28, Anders Dahnielson wrote: > Now to the flaky bit. While "play", "stop" and "location" works fine, > hitting record in Rosegarden to record MIDI tracks does not. Rosegardens > behavior then becomes slightly antsy. Whenever I hit play the location will > start to jump all over the place until finally stopping three seconds into > the song (if I remember the time correctly). To get rid of the behavior I > need to restart Rosegarden altogether. I'm sorry if this sounds dumb, but can you try to explain exactly how you reproduce this behaviour (assuming a willing MMC slave device)? I mean in a very simplistic step-by-step way for stupid readers, preferably in a process that you can actually test as you write it, with a real machine. Chris |
From: Anders D. <an...@da...> - 2007-04-24 11:04:49
|
On 4/23/07, Chris Cannam <ca...@al...> wrote: > > On Monday 23 April 2007 13:28, Anders Dahnielson wrote: > > Now to the flaky bit. While "play", "stop" and "location" works fine, > > hitting record in Rosegarden to record MIDI tracks does not. Rosegardens > > behavior then becomes slightly antsy. Whenever I hit play the location > will > > start to jump all over the place until finally stopping three seconds > into > > the song (if I remember the time correctly). To get rid of the behavior > I > > need to restart Rosegarden altogether. > > I'm sorry if this sounds dumb, but can you try to explain exactly how you > reproduce this behaviour (assuming a willing MMC slave device)? I mean in > a > very simplistic step-by-step way for stupid readers, preferably in a > process > that you can actually test as you write it, with a real machine. > > Sure can do. That was what I had in mind. I just threw the message together since the topic was discussed. Hopefully I will be able to reproduce it with debug info on so there's a log to go along with it. I'll be back. :-) -- Anders Dahnielson <an...@da...> |
From: Anders D. <an...@da...> - 2007-04-24 17:00:34
|
On 4/23/07, Chris Cannam <ca...@al...> wrote: > > On Monday 23 April 2007 13:28, Anders Dahnielson wrote: > > Now to the flaky bit. While "play", "stop" and "location" works fine, > > hitting record in Rosegarden to record MIDI tracks does not. Rosegardens > > behavior then becomes slightly antsy. Whenever I hit play the location > will > > start to jump all over the place until finally stopping three seconds > into > > the song (if I remember the time correctly). To get rid of the behavior > I > > need to restart Rosegarden altogether. > > I'm sorry if this sounds dumb, but can you try to explain exactly how you > reproduce this behaviour (assuming a willing MMC slave device)? I mean in > a > very simplistic step-by-step way for stupid readers, preferably in a > process > that you can actually test as you write it, with a real machine. > > This is weird. After rebuilding Rosegarden with debuging turned on the behavior disappeared. An Heisenbug! Will fiddle around with it a bit more and see if I can find anything that might have triggered it before... -- Anders Dahnielson <an...@da...> |
From: Anders D. <an...@da...> - 2007-04-24 17:12:46
|
On 4/24/07, Anders Dahnielson <an...@da...> wrote: > > > > On 4/23/07, Chris Cannam <ca...@al...> wrote: > > > > On Monday 23 April 2007 13:28, Anders Dahnielson wrote: > > > Now to the flaky bit. While "play", "stop" and "location" works fine, > > > hitting record in Rosegarden to record MIDI tracks does not. > > Rosegardens > > > behavior then becomes slightly antsy. Whenever I hit play the location > > will > > > start to jump all over the place until finally stopping three seconds > > into > > > the song (if I remember the time correctly). To get rid of the > > behavior I > > > need to restart Rosegarden altogether. > > > > I'm sorry if this sounds dumb, but can you try to explain exactly how > > you > > reproduce this behaviour (assuming a willing MMC slave device)? I mean > > in a > > very simplistic step-by-step way for stupid readers, preferably in a > > process > > that you can actually test as you write it, with a real machine. > > > > > This is weird. After rebuilding Rosegarden with debuging turned on the > behavior disappeared. An Heisenbug! > > Will fiddle around with it a bit more and see if I can find anything that > might have triggered it before... > Ok, just seconds after hitting send and when I stopped saving the error output in a logfile it started to behave antsy all over again... -- Anders Dahnielson <an...@da...> |
From: Vince N. <vin...@gm...> - 2007-04-25 07:12:32
|
Do you have access to the list archives? Look at my thread titled "[Patch] interaction of MMC master and MTC slave" from July of last year. It sounds like you may be running into a similar problem. On 24/04/07, Anders Dahnielson <an...@da...> wrote: > On 4/24/07, Anders Dahnielson <an...@da...> wrote: > > > > > > > On 4/24/07, Anders Dahnielson < an...@da...> wrote: > > > > > > > > On 4/23/07, Chris Cannam < ca...@al...> wrote: > > > > > > > I'm sorry if this sounds dumb, but can you try to explain exactly how > you > > > > reproduce this behaviour (assuming a willing MMC slave device)? I > mean in a > > > > very simplistic step-by-step way for stupid readers, preferably in a > process > > > > that you can actually test as you write it, with a real machine. > > > > > > > > > > > > > > This is weird. After rebuilding Rosegarden with debuging turned on the > behavior disappeared. An Heisenbug! > > > > > > Will fiddle around with it a bit more and see if I can find anything > that might have triggered it before... > > > > > > > > > > Ok, just seconds after hitting send and when I stopped saving the error > output in a logfile it started to behave antsy all over again... > > This is the quickest way for me to reproduce the behavior: > > Setup: Rosegarden as MMC master and MTC slave. Korg D12 as MMC slave and MTC > master. My computer and the D12 is connected by via a dedicated MIDI > interface. > > 1) Start Rosegarden. > > 2) Make sure a MIDI track is armed. > > 3) Open the transport dialog (the 't' shortcut). > > 4) Press record, record a bar or more, press record again to halt. > > 5) Repeat step #4 several times. > > 6) The position will start to jump all over the place. Stopping at > 000:00.400 (MSM) or 001.01.061 (MBT) according to the D12's counter. > > The debug error output log is attached as gziped text file. > > -- > > Anders Dahnielson > <an...@da...> > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Rosegarden-devel mailing list > Ros...@li... - use the link below > to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel > > |
From: Anders D. <an...@da...> - 2007-04-25 11:11:51
|
On 4/25/07, Vince Negri <vin...@gm...> wrote: > > Do you have access to the list archives? Look at my thread titled > "[Patch] interaction of MMC master and MTC slave" from July of last > year. It sounds like you may be running into a similar problem. > > I found it in the archives. Now being nine or ten month after the fact, shouldn't that patch have propagated into the stable 1.5 branch? -- Anders Dahnielson <an...@da...> |
From: Anders D. <an...@da...> - 2007-04-25 16:40:04
|
On 4/25/07, Anders Dahnielson <an...@da...> wrote: > > > On 4/25/07, Vince Negri <vin...@gm...> wrote: > > > > Do you have access to the list archives? Look at my thread titled > > "[Patch] interaction of MMC master and MTC slave" from July of last > > year. It sounds like you may be running into a similar problem. > > Yes, it looks like the same problem. Thanks for pointing out the patch. I found it in the archives. > > Now being nine or ten month after the fact, shouldn't that patch have > propagated into the stable 1.5 branch? > > The patch in question is indeed applied to the branch. However, it looks like the race condition is still taking place. -- Anders Dahnielson <an...@da...> |