Skip to main content ↑ ↓
Topic: MIDI exporting bug? (Read 6269 times) previous topic - next topic

MIDI exporting bug?

I first started using Noteworthy Composer in December 1998, and when version 2 came out, I switched to that and found it to be a big improvement as regards creating and printing scores.  It is also fine for creating regular Type 0 MIDI files that will be played through a General MIDI keyboard or the GS wave table synth of a computer sound card.
But for creating custom MIDI files to control our church’s pipe organ, version 2.75 does not behave like version 1.75.  In particular it does not correctly export the *.nwc file as a *.mid file, and to get round the problem I have found it necessary to continue using version 1.75.
Basically, the problem is this:
Controlling the registration (changing the stops) on the organ is achieved by means of program change messages on MIDI channel 16.
At the start of a piece, several stops need to be drawn, and several stops may be changed simultaneously at intervals during the piece.
To achieve this, I insert strings of program change messages at the appropriate places on the Noteworthy stave that is configured to MIDI channel 16.  The program change messages then toggle the corresponding organ stops at the appropriate points in the music.
In the case of Noteworthy 1.75, the strings of program changes are accurately exported to the final MIDI file, but in the case of version 2.75, only some of the program changes find their way into the MIDI file, resulting in rubbish registrations.
I have tried inserting short rests between the program changes, but this doesn’t really fix the problem and in any case it is not always practical.
Some considerable time ago, and again more recently I wrote to Noteworthy Support about this, but never received a reply, so I am raising the matter here in case any of you guys can offer any advice or perhaps simply confirm that it is a “bug”.

Re: MIDI exporting bug?

Reply #1 –
Hello Graham,

I don't know if this will help in your specific situation, but there was a topic posted a while back around someone's need to send MIDI RPN and NRPN messages to control their church organ, so a custom object was created to assist with this. Custom objects are a feature in version 2.75 that allow new functions and features to be easily added to NWC. Check out this thread for more information about the MIDIPARM.nw object, to see if it would work with your organ.

Re: MIDI exporting bug?

Reply #2 –
I have some tools that examine MIDI files. If you could attach some nwc files that drop program changes, I'll have a look at them.
Registered user since 1996

Re: MIDI exporting bug?

Reply #3 –
Thank you Mike and Rick for your speedy responses.
@ Mike:
I looked at the thread you mentioned, but I don't think I can get my head round the content of it!  The MIDI implementation of our organ is much less complex than that of an Allen.
When I was using NWC v 1.75 I edited the NTWPATCH.INI to include the organ stop list.  With NWC v 2.75, I created an itree of the stop list.  So in either case it was easy simply to insert Instrument Changes into the Noteworthy score.
@ Rick:
Since starting this thread, I have just tried controlling my organ at home directly from Noteworthy Composer 2.75 rather than using a MIDI file.  I had done this in the past with version 1.75 and I knew it worked.  I thought it also worked with version 2.75 - but I've just discovered it doesn't!  The same thing happens as with a MIDI file created using version 2.75 - only a fraction of the stops are activated.
So the problem is not that version2.75 does not export MIDI files correctly (as I thought) but rather, it does not handle a string of Instrument Changes in the same way as version 1.75 does.
Attached is the NWC file that I have just been experimenting with.  It was originally created (and works) with version 1.75 but it doesn't work when played using version 2.75.
With version 2.75, only one or two of the initial bunch of stops are activated.

Re: MIDI exporting bug?

Reply #4 –
I''m very puzzled!
How can your organ know to which manual you want to apply those stops since all the stop changes are made in channel 16?
Maybe it has only one manual (and no pedalboard)?

Re: MIDI exporting bug?

Reply #5 –
Trust me - it works!
Swell manual responds to Note-on/off messages on Channel 1.
Great manual responds to Note-on/off messages on Channel 2.
Choir manual responds to Note-on/off messages on Channel 3.
Pedal-board responds to Note-on/off messages on Channel 4.
Expression pedal responds to CC (Foot Pedal) messages on Channel 1.
Stops and Couplers respond to (are toggled on or off by) Program Change (Instrument Change) messages on Channel 16.
You can see which stop responds to which message from the itree that I attached.
My Hauptwerk organ at home is configured to behave exactly as the Church pipe organ which has a solid state console with MIDI in and out ports.
Hope this dispels the confusion!

Re: MIDI exporting bug?

Reply #6 –
Sorry, I missed the "prefix" of each "voice": "SW", "CH", "GT" etc.
Now I understand.

Re: MIDI exporting bug?

Reply #7 –
Hi GrahamH,
I notice that you are sending Bank Select data in the instrument change.  That's fine, but I was wondering if the bank selection data is correct?  There is no Bank Select data in the itree you posted so it is defaulting to 0,0.  This is not to say that is not correct as it may very well be, but can you confirm this please?

I no longer have access to my old ntwpatch.ini to compare against, but perhaps you could attach a copy of yours anyway so we can investigate.

FWIW it make no sense to me that 2.75 wouldn't send a correct MIDI data stream unless it's getting incorrect setup information in the first place.  Of course, I've been known to be wrong before, on at least, ooh, several occasions  ;)

Perhaps you could also post a v1.75 .nwc file that works correctly too.  Hopefully the conversion process won't alter the instrument patch data during the import.
I plays 'Bones, crumpets, coronets, floosgals, youfonymums 'n tubies.

Re: MIDI exporting bug?

Reply #8 –
This is just me taking a SWAG[1], but I wonder if NWC 2.75 might not be "optimizing" things by removing redundant back-to-back program changes to the same channel that don't have any notes between them. I notice in a few cases in the sample score, there are short duration rests between some of the program changes, presumably because the organ needed some time to process them. Perhaps as a test, 32nd rests could be inserted between the runs of program changes, to see if that causes them to be present in the output stream.  I don't have the MIDI tools that @Rick G. does so I can't easily test or verify this.
Edit: I decided to find myself a MIDI editor and see if I could verify my own guesses above. I exported the original sample file to MIDI Type 0 and opened it in the editor. In the first measure, I could see three program changes, which corresponded to the first two (that were bracketed by rests) and the first in the group of 8 consecutive program changes.  I then reopened the sample score and inserted 64th rests between each of the 8 consecutive program changes, re-exported the file and opened it in the editor[2]. Now, I could see that all program changes were present in the stream.  So, at a minimum, I've shown that inserting rests between consecutive program changes will make them work with 2.75. Whether there is a better workaround for this is something I haven't yet explored.
1 Scientific Wild-Assed Guess↵
2 I also added equivalent rest amounts in the other staves to keep things lined up↵

Re: MIDI exporting bug?

Reply #9 –
Many thanks for all your replies.
If nothing else, starting this thread has made me look more carefully into what is happening and, as I said in my earlier post, I now realise that the problem is not that version 2.75 does not export MIDI files correctly (as I thought) but rather, version 2.75 does not handle a string of Instrument Changes in the same way as version 1.75 does.
For generating “ordinary” MIDI files, where there is typically only one General MIDI instrument patch per track at any one time, version 2.75 is fine.  But for my scenario which involves strings of instrument changes on one track, neither NWC files nor MIDI files created using version 2.75 will work.  On the other hand, NWC files and MIDI files created using version 1.75 both work perfectly.

@ Lawrie:
Since my stop list consists of only one “bank” containing fewer than 127 “instruments” the default Bank Select parameters (0,0) are fine.
My old NTWPATCH.INI is attached (in a zip file).  It won’t tell you anything more than the itree  that I already posted does, but it might enable you to see what’s happening in Noteworthy v 1.75.
The file that I posted two days ago works with v 1.75, but I am attaching to this post versions of the same new NWC and MIDI files (created yesterday with the aid of a template) for v 1.75 and v 2.75.  Those saved from v 1.75 work; those saved from v 2.75 don’t.

@ Mike
I made a similar “SWAG” to yours when I first encountered the problem several years ago, and I tried inserting rests between the instrument patches.  However, I found that the rests needed to be bigger than 1/64 ths, and even then they weren’t entirely reliable.  Also, while it was practicable to insert rests in the initial string of program changes, it was not feasible to do so at later points in the score, where a pretty rapid change of registration is called for.

Since I have now discovered that it is possible to run both v 1.75 and v 2.75 on the same computer the obvious “solution” is to use v 2.75 for printing scores and generating “ordinary” MIDI files, but to use v 1.75 for generating custom MIDI files for controlling the organ.
Actually, because I prefer v 2.75’s “itree” system which attaches the stop names to the instrument patches, and since I have also discovered that v 2.75 will export v 1.75 NWC files (Has it always done so?), the work-around that I favour is:
Create the NWC file using v 2.75
Export it as a v 1.75 file
Open it using v 1.75
Save it from v 1.75 as a type 0 MIDI file   –  which is how I produced the attached files.

(PS - All this arose because of Covid-19 and a request to record organ music for virtual services!)

Best regards
Graham

Re: MIDI exporting bug?

Reply #10 –
Quote from: GrahamH –
... since I have also discovered that v 2.75 will export v 1.75 NWC files (Has it always done so?), the work-around that I favour is:
Create the NWC file using v 2.75
Export it as a v 1.75 file
Open it using v 1.75
Save it from v 1.75 as a type 0 MIDI file  –  which is how I produced the attached files.
This will only work as long as you don't use any new 2.75 features that would be stripped from the file when you save in 1.75 format. This would include custom objects for things like arpeggios, tremolos and the like.

In short, I consider the current 2.75 behavior as a "bug". It might have been an intentional change of behavior by the author, but it now appears that the previous behavior is something that is desired, at least for certain playback situations.

Re: MIDI exporting bug?

Reply #11 –
Thanks for the warning!
I guess it won't happen with straightforward material like hymn tunes.  But if I get a bit more ambitious and try to sequence some voluntaries, as I did several years ago, it might become an issue.
Graham
 

Re: MIDI exporting bug?

Reply #12 –
Quote from: GrahamH –
<snip>
@ Lawrie:
Since my stop list consists of only one “bank” containing fewer than 127 “instruments” the default Bank Select parameters (0,0) are fine.
My old NTWPATCH.INI is attached (in a zip file).  It won’t tell you anything more than the itree  that I already posted does, but it might enable you to see what’s happening in Noteworthy v 1.75.
The file that I posted two days ago works with v 1.75, but I am attaching to this post versions of the same new NWC and MIDI files (created yesterday with the aid of a template) for v 1.75 and v 2.75.  Those saved from v 1.75 work; those saved from v 2.75 don’t.
<snip>

Thanks Graham.
RE bank info: makes sense.
RE ntwpatch.ini - thank you - confirms what you say,
RE MIDI files - I was hoping to find a MIDI analyzer to download that would let me see if the two matched as far as MIDI data was concerned, but the ones I found wouldn't show the changes on channel 16 - still looking but now not holding my breath.  Maybe Rick has something that will tell the story.

I'd hoped to be more helpful, but for the moment I'm out of ideas,

Lawrie
I plays 'Bones, crumpets, coronets, floosgals, youfonymums 'n tubies.

Re: MIDI exporting bug?

Reply #13 –
Quote from: Lawrie Pardy –
RE MIDI files - I was hoping to find a MIDI analyzer to download that would let me see if the two matched as far as MIDI data was concerned, but the ones I found wouldn't show the changes on channel 16 - still looking but now not holding my breath.  Maybe Rick has something that will tell the story.
Hi Lawrie,

I downloaded and installed the free program MidiEditor which appears to show notes and messages from all channels. However, for some reason this program numbers the channels from 0 to 15 rather than 1 to 16.  This is the program which I used to confirm my "64th rest" workaround. The program appears to work on Windows XP and later, although I only ran it on Windows 10.

Re: MIDI exporting bug?

Reply #14 –
Quote from: Mike Shawaluk –
Hi Lawrie,

I downloaded and installed the free program MidiEditor which appears to show notes and messages from all channels. However, for some reason this program numbers the channels from 0 to 15 rather than 1 to 16.  This is the program which I used to confirm my "64th rest" workaround. The program appears to work on Windows XP and later, although I only ran it on Windows 10.

This is quite common with MIDI stuff - they start counting at zero instead of one - and it can be quite confusing!
Graham

Re: MIDI exporting bug?

Reply #15 –
Here is a zip file with 4 variants of diff output for the Hallelujah175/275 files (the CSV was created with the MIDICSV utilitiy found at fourmilab - the only such tool I know that works after Günther Nagler's even older one stopped working some Windowses ago). Maybe someone can see and explain the 1.75/2.75 differences with that ... I'm currently involved with other projects (and problems), therefore I don't dig into this ...

Edit: The c175_275.txt seems most useful/readable ...

H.M.

Re: MIDI exporting bug?

Reply #16 –
Quote from: GrahamH –
This is quite common with MIDI stuff - they start counting at zero instead of one - and it can be quite confusing!
Graham
And NWC itself sometimes does count from 1, someother times counts the same thing from 0...

Re: MIDI exporting bug?

Reply #17 –
There are 10 kinds of people: those who understand binary, and those who don't.

Re: MIDI exporting bug?

Reply #18 –
There are two types of people: those who can extract information from incomplete data
Since 1998

Re: MIDI exporting bug?

Reply #19 –
If you want to make a list what's important when you're programming:
  • 0:  Always start counting from 0.
  • 1: In lua, start from 1.
Always look on the bright side of life!

Re: MIDI exporting bug?

Reply #20 –
Quote from: Opagust –
If you want to make a list what's important when you're programming:
  • 0:  Always start counting from 0.
  • 1: In lua, start from 1.
That was the hardest part of learning to create custom NWC objects... old habits die hard!