From: Insidious B. <ins...@gm...> - 2013-01-05 08:44:04
Attachments:
13edo-scale.rg
13edo-scale.mid
|
Hello Rosegarden world, I have recently become able to get Rosegarden to make sound (by compiling it) and am also developing games for mobile phones which use MIDI as the main sound production method so have come to get more acquainted with Rosegarden. In the summer, I was having a hard time getting what I wanted out of Rosegarden, which was microtunings. These are notes or systems of notes different from the 12-pitches-per-octave Western scale. I did see the pitch bend ruler, but drawing bends with the draw tool was not precise enough and at the time I just gave up as I mainly use Csound and ZynAddSubFX, which have native support for alternate tunings. Fast forward to a few weeks ago when I downloaded the 12.04 (and now 12.12) source code and compiled it on my Trisquel 5.5 64-bit netbook. After compiling, I actually got real-time sound, which I had never experienced before and which is a thrill and great help. However, I did encounter one obstacle: exporting to a MIDI file seems to mess up a little bit. I created a file which had a chromatic scale (all pitches included) of the system called 13EDO (equal divisions of the octave). The native .rg was fine and ran to 8 bars, but when I exported it to MIDI, and played it on one of my development phones, one of the notes was dead, and the MIDI file was extended to over a minute with just silence. In other words, more blank bars were added to the MIDI for seemingly no reason. As I export the same file now from 12.12 (I used 12.04 at the time) the "dead note" does not occur again, but the file is still extended to a full 100 bars when exported to MIDI. I praise 12.12 for being the least crash-prone version of Rosegarden I have ever used, but there is this small little niggle to work out. I have provided both the .rg and .mid files and invite you to re-create the .mid with its error. For the record, I have another netbook that is still running Rostegarden 11.06 Don Juan and it exports MIDI's without the said error. I have been awkwardly composing in 12.12, and tranferring files via USB flashdrive to my 11.06 setup where I export. It works for now but may get tedious. Once again, thank you all who develop Rosegarden. Now that I know how to get precise pitch bends via the Event List Editor, I think Rosegarden is the crown jewel of the Free Software MIDI editor world. It is every bit as good as, say, Sibelius, which is what has been used to make most of the micro-tonal MIDI examples on Wikipedia to date. I plan to change that and contribute many additional pitch-bent MIDI files authored in Rosegarden. Thank you for your time and I look forward to working with you. |
From: Insidious B. <ins...@gm...> - 2013-01-09 05:31:15
|
This is not meant to annoy or re-post unnecessarily, but I have just built 12.12.25 from source and can report that the same problem is still there, on a short file, when exporting to MIDI, Rosegarden extends it to 100 bars with extra empty space. Maybe it is just on my machine, but see the attached files for verification. Thank you. On 1/5/13, Insidious Blank <ins...@gm...> wrote: > Hello Rosegarden world, > I have recently become able to get Rosegarden to make sound (by > compiling it) and am also developing games for mobile phones which use > MIDI as the main sound production method so have come to get more > acquainted with Rosegarden. In the summer, I was having a hard time > getting what I wanted out of Rosegarden, which was microtunings. These > are notes or systems of notes different from the 12-pitches-per-octave > Western scale. I did see the pitch bend ruler, but drawing bends with > the draw tool was not precise enough and at the time I just gave up as > I mainly use Csound and ZynAddSubFX, which have native support for > alternate tunings. Fast forward to a few weeks ago when I downloaded > the 12.04 (and now 12.12) source code and compiled it on my Trisquel > 5.5 64-bit netbook. After compiling, I actually got real-time sound, > which I had never experienced before and which is a thrill and great > help. However, I did encounter one obstacle: exporting to a MIDI file > seems to mess up a little bit. I created a file which had a chromatic > scale (all pitches included) of the system called 13EDO (equal > divisions of the octave). The native .rg was fine and ran to 8 bars, > but when I exported it to MIDI, and played it on one of my development > phones, one of the notes was dead, and the MIDI file was extended to > over a minute with just silence. In other words, more blank bars were > added to the MIDI for seemingly no reason. As I export the same file > now from 12.12 (I used 12.04 at the time) the "dead note" does not > occur again, but the file is still extended to a full 100 bars when > exported to MIDI. > > I praise 12.12 for being the least crash-prone version of Rosegarden I > have ever used, but there is this small little niggle to work out. I > have provided both the .rg and .mid files and invite you to re-create > the .mid with its error. > > For the record, I have another netbook that is still running > Rostegarden 11.06 Don Juan and it exports MIDI's without the said > error. I have been awkwardly composing in 12.12, and tranferring files > via USB flashdrive to my 11.06 setup where I export. It works for now > but may get tedious. > > Once again, thank you all who develop Rosegarden. Now that I know how > to get precise pitch bends via the Event List Editor, I think > Rosegarden is the crown jewel of the Free Software MIDI editor world. > It is every bit as good as, say, Sibelius, which is what has been used > to make most of the micro-tonal MIDI examples on Wikipedia to date. > > I plan to change that and contribute many additional pitch-bent MIDI > files authored in Rosegarden. > > Thank you for your time and I look forward to working with you. > -- Avatar image courtesy of Wikimedia Commons user Twice25 retrieved from: http://commons.wikimedia.org/wiki/File:Verona_-_maschera_veneziana.jpg |
From: D. M. M. <ros...@gm...> - 2013-01-09 12:11:18
|
On 01/09/2013 12:31 AM, Insidious Blank wrote: > This is not meant to annoy or re-post unnecessarily, but I have just > built 12.12.25 from source and can report that the same problem is > still there I filed a bug report. We'll work around to looking at it sooner, rather than later. -- D. Michael McIntyre |
From: Insidious B. <ins...@gm...> - 2013-01-17 05:02:53
|
In line with what I mentioned, I have discovered another problem with 12.x in exporting MIDI files. I opened a 32 track orchestral .mid to change one instrument, and went to export. When I listened to the file with Timidity, all the other tracks were silent, except for the one I changed. I reproduced this twice. I tried the same thing on my netbook with 11.06, and just like I mentioned before with the other issue, it exported perfectly- all the tracks I did not change were audible and the one I did change sounded different. It looks like somewhere along the line there was something that got broken with the MIDI export function, perhaps? Once again, I will use 11.06 or older to export, but 12.12.25 to compose as it is less crash prone. |
From: D. M. M. <ros...@gm...> - 2013-01-17 05:27:28
|
> but 12.12.25 to compose as it is less crash prone. Why don't you try current SVN where we think the MIDI export bug is fixed? If it's not fixed, there's still time to do something about it. -- D. Michael McIntyre |
From: Insidious B. <ins...@gm...> - 2013-01-17 07:19:45
|
Okay, as of 12:18 AM Mountain Time on Thursday, Jan 17, I am going to get the current code, compile it, and put it to the test. I will report as soon as I know. |
From: Insidious B. <ins...@gm...> - 2013-01-17 08:35:41
|
All right, I have verified that with the 13.02 snapshot, both problems I noted still exist. Exporting a short .rg file to MIDI will cause it to have 100 tracks total even if the .rg has only a few bars of actual content. Also, importing a .mid and changing one instrument setting and re-exporting will result in all other instruments except the changed one not being heard. Version 11.06 (and perhaps earlier) does not have this problem. (is needing a sf user and password new? Luckily I had one set up only months ago...) |
From: D. M. M. <ros...@gm...> - 2013-01-17 08:52:36
|
On 01/17/2013 03:35 AM, Insidious Blank wrote: Thanks for trying this with SVN. Now you'll be in position to test any fixes that emerge. > I noted still exist. Exporting a short .rg file to MIDI will cause it > to have 100 tracks total even if the .rg has only a few bars of actual 100 tracks or 100 bars/measures? > Also, importing a .mid and changing one instrument setting > and re-exporting will result in all other instruments except the > changed one not being heard. Can you give a repeatable step by step example, just to make sure I'm doing exactly what you're doing when I test? -- D. Michael McIntyre |
From: Insidious B. <ins...@gm...> - 2013-01-19 02:33:12
|
Sorry, I meant 100 bars/measures, not tracks. For a step by step example: open a .mid file with Rosegarden. For my file, which is too big to include, I selected track #5 and changed the instrument program from Church Organ to Clarinet. Then I exported a MIDI file named something new. When I listened to the new MIDI file, only the changed track was heard and it also played immediately when it was originally supposed to come in later. Listening to the original .mid file, it played fine with all tracks heard, and the Church Organ track #5 coming in when it was supposed to. Hopefully you can see the errors I am describing and they are something trivial. |
From: Tom B. (Tehom) <te...@pa...> - 2013-01-19 05:07:23
|
> For a step by step example: > open a .mid file with Rosegarden. For my file, which is too big to > include, I selected > track #5 and changed the instrument program from Church Organ to > Clarinet. It would be helpful if you included a file that this happens with. If it's too big, perhaps just the first few bars, but check that it still has the bug. I can't guess what makes this different than MIDI files that work right. Tom Breton (Tehom) |
From: Insidious B. <ins...@gm...> - 2013-01-19 07:45:13
Attachments:
problem-mid.zip
|
> It would be helpful if you included a file that this happens with. If > it's too big, perhaps just the first few bars, but check that it still has > the bug. I can't guess what makes this different than MIDI files that > work right. > I hope it is permissible, I am adding the file zipped. I could not quickly select all 32 tracks and resize them to a few bars. Try the changes to track 5 that I did and see what happens. |
From: D. M. M. <ros...@gm...> - 2013-01-19 11:59:16
|
> I hope it is permissible, I am adding the file zipped. That's perfect. Thanks. I tried changing the program on track 5 and exporting back to .mid I'm not in a position to listen to anything right now, so literally all I did was look. I opened the resulting .mid file in MusE, and compared the structure. The structure looks the same at a glance. For giggles, I started over from scratch, loaded your file again, and exported it straight out without changing anything. Next, I changed the one program, and exported it again. Finally, I compared hex dumps of the two binary files. The ONLY difference between the hex dumps is that one has 0x13 where the other has 0x38. I used Trumpet instead of Clarinet. 0x38 is 56 decimal is Trumpet, 0x13 is 20 decimal is Church Organ. There's your change. That is the ONLY change. If one file plays, the other file should play too. If one of them doesn't, the other one won't either. The kind of gross behavioral differences you're describing cannot possibly be explained by these two bytes alone. I conclude, therefore, I have not successfully repeated your bug. It's just not happening here. Why don't we get on the same page and see what results you get repeating my experiment (including using Trumpet instead of Clarinet) in your own laboratory? 1. ./rosegarden or-pine2.mid 2. File -> Export -> Export MIDI File - export it as "before.mid" 3. Change the program on track 5 from Church Organ to Trumpet 4. File -> Export -> Export MIDI File - export it as "after.mid" 5. hexdump before.mid > before.hex 6. hexdump after.mid > after.hex 7. diff -U 0 before.hex after.hex Here is my result: -> diff -U 0 before.hex after.hex --- before.hex 2013-01-19 05:39:09.000000000 -0500 +++ after.hex 2013-01-19 05:40:49.000000000 -0500 @@ -1179 +1179 @@ -0005b20 002e 00b4 0000 0020 c400 0013 79b4 0000 +0005b20 002e 00b4 0000 0020 c400 0038 79b4 0000 @@ -1511 +1511 @@ -0007510 2e72 b500 0000 2000 0000 13c5 b500 0079 +0007510 2e72 b500 0000 2000 0000 38c5 b500 0079 I repeated this entire procedure twice with the same results both times. What do you get? -- D. Michael McIntyre |
From: D. M. M. <ros...@gm...> - 2013-01-19 11:21:44
|
> is Trumpet, 0x13 is 20 decimal is Church Organ. 19 decimal. That was a typo. The programs are 57/20 in "human" form, 56/19 in "computer" form, and 0x38/0x13 in hexadecimal. I realized I hadn't been using the very latest SVN for these tests, so I built the newest changes and did it all over again with the same result a third time. When I think about it, I'm very impressed that Rosegarden is exporting the same thing byte for byte every time, and that is so beautifully clear and unmistakable that the only change from version A to version B is the one and only the one change we expect. On MY computer anyway. Now watch you post a diff 500 lines long where we're corrupting the hell out of it on YOUR computer. :) -- D. Michael McIntyre |
From: Insidious B. <ins...@gm...> - 2013-01-19 20:41:10
|
> > -> diff -U 0 before.hex after.hex > --- before.hex 2013-01-19 05:39:09.000000000 -0500 > +++ after.hex 2013-01-19 05:40:49.000000000 -0500 > @@ -1179 +1179 @@ > -0005b20 002e 00b4 0000 0020 c400 0013 79b4 0000 > +0005b20 002e 00b4 0000 0020 c400 0038 79b4 0000 > @@ -1511 +1511 @@ > -0007510 2e72 b500 0000 2000 0000 13c5 b500 0079 > +0007510 2e72 b500 0000 2000 0000 38c5 b500 0079 > > I repeated this entire procedure twice with the same results both times. > What do you get? I got: diff -U 0 before.hex after.hex --- before.hex 2013-01-19 13:29:39.256867945 -0700 +++ after.hex 2013-01-19 13:29:52.052931413 -0700 @@ -1179 +1179 @@ -0005b20 002e 00b4 0000 0020 c400 0013 79b4 0000 +0005b20 002e 00b4 0000 0020 c400 0038 79b4 0000 @@ -1511 +1511 @@ -0007510 2e72 b500 0000 2000 0000 13c5 b500 0079 +0007510 2e72 b500 0000 2000 0000 38c5 b500 0079 the only difference seems to be the -0700 part, which I have no idea about. What I can tell you is that both files are "messed up", that is is you listen to the original, untouched file, all tracks will play and track 5 starts playing a few seconds in (as Church Organ). The simple act of exporting from Rosegarden jumbles things up so that the Church Organ starts playing immediately and, as with the modified file, only that track 5 is audible. The reason there is little difference between the 2 files is that they both have the same error. I get a VERY big difference between the hexdump for the original or-pine2.mid file and before.hex, let me know if you are interested. |
From: D. M. M. <ros...@gm...> - 2013-01-19 22:05:34
|
On 01/19/2013 03:41 PM, Insidious Blank wrote: > What I can tell you is that both files are "messed up", That makes a lot more sense than the hypothesis that changing the program causes all the carnage to happen. The program change is not the problem. Just exporting the file to MIDI at all is the problem. Looking at the ORIGINAL in MusE and then comparing it with our version, it seems obvious the stuff that was supposed to start at the beginning has disappeared completely. Changes in track structure and part ordering are normal, but nothing is supposed to disappear. More investigation required. I'll have more time tomorrow night. > I get a VERY big difference between the hexdump for the original > or-pine2.mid file and before.hex, let me know if you are interested. That wouldn't show anything interesting, because Rosegarden doesn't work with .mid files directly. Loading it involves converting it to an entirely different format, and exporting it involves converting it back. The result will always be different, though it's supposed to come out sounding the same. -- D. Michael McIntyre |