You know what would be a cool addition? Build a "macro" file with a set number of MIDI data , saved either in the basic ini file or another one, like macros.ini. Trigger this with a key command, then a dialog box pops up asking for the macro name, which is polled in a drop down list like the inst files. These macros could consist of controller messages including RPN and NRPN data, SysEx message strings, note messages like arpeggio files or step sequences, or just about any type of MIDI message that isn't clock based. (Because including clock or timing messages would run the risk of confusing the program) You'd probably need to do all of this in hex, but it wouldn't be difficult to include a document that outlines all of these hexadecimal codes and their assignments for non-system exclusive stuff. (The sysex codes would need to be pulled from the documentation of same for individual instruments, and would also, of course, have to include the end of sysex message at the end) This macro would insert at the current point in the track. Some that had things happening over time might need to have some sort of time marker, too, though I think there are actually ways around that. They wouldn't have to be entered by hand either, as a second command would paste the highlighted area to one of these macros. I'm thinking a list of a thousand of these, (000-999) to make sure that nobody runs out, as if you've got a couple of soft synthesizers you could break a hundred of these. This wouldn't be that hard to implement, from a logic perspective at least, and it wouldn't get in the way of the standard MIDI file data either. In fact, if it loaded a standard MIDI file for its data it could even be something the user creates in QWS and then saves to use for inserting things. This would be great for inserting all kinds of things -- drum loops, volume fades or increases, tempo changes, all kinds of stuff. Just a thought. We wouldn't need a save and load command if it was a standard MIDI file, just the insert command that pulls the box up to pick which one to use.
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Paul Nimmo > Sent: Thursday, February 26, 2015 7:17 PM > To: QWS list > Subject: Re: QWS List Thoughts and qws suggestions for more advanced > MIDI users > > Hi, um, mate, please don't take this as a flame because it's not, it's > just a word. > sysex, or to those who actually do advanced midi work, sisex, often > spelt in case anyone's googling them, are just that, system exclusive. > Because of that, they are a pain by nature but can also be very useful > and very powerful. > Not only each brand of synthesizer, but in many cases individual synths > by the same brand, have different ways of dealing with these. > they have always been and will always be cumbersome. > Also, there's no way to actually interrogate a system to find out what > sysex messages it will process/send andor why. > E.g. my son and I have very similar Yamaha keyboards but the sysex > messages don't even look the same. > i doubt this could be coded but if it could it would elevate the price > of the program to a point where nobody could afford it, even if James > was even half way reasonable with charges based on time. > As it is I can't believe James doesn't charge for qws and if he did, > I'd be a buyer. > > As for 1 there's a little trick you can do to get around this but I see > Nicole has already written it up, thanks for that, I would have done it > as we use the same method for almost the same reason, I grew up using > power trax, lol! > hth. > Cheers! > > > -----Original Message----- > From: arfy > Sent: Sunday, February 22, 2015 6:51 PM > To: QWS list > Subject: QWS List Thoughts and qws suggestions for more advanced MIDI > users > > Hi, all. I thought I'd write down here my thoughts and ideas for those > of us who like to do some pretty advanced midi tricks, such as dealing > with sets of controllers, particularly NRPN messages, working with > sysex messages, and a possible alternative way of viewing and working > with midi events. This will be semi-long, just as a heads up. > > 1. sets of controllers. > > While I love working with the qws event list editor, it can get a > little tedious when inputting sets of often, 3, sometimes even 4 > controllers to use NRPN (non-registered parameter number) messages. For > example, to set the pitch of a snare drum, three controllers need to be > sent, in a particular order, such that data entry controller number 6 > is always sent last. It would be nice if all the controllers could just > be inserted, all at the same time, and most midi players/sequencers > seem to handle this fine. qws, however, resorts the controllers so that > all the data entry messages come first, then all controller 98 > messages, and finally controller 99. To work around this, I place the > data entry controller a tick after the rest, which works, but can get > annoying when dealing with a hole string of these. See number 3, below > for a possible suggestion here. > > 2. working with sysex. > > While qws has full support for sysex messages, working with them can be > quite brain taxing! You have to not only remember the strings to > insert, but some manufacturers (ahem, roland?) require individual > parameter changes have a checksum calculated for each of them! > Even something as simple as a checksum calculator would be nice here, > but my idea, and this may be going beyond the scope of James' vision > for qws, would be to have some sort of patch editing/librarian as part > of the program. You could have mini scripts, or settings in ini files > that set up the parameter names, and the messages for each one. I offer > this suggestion because, unfortunately, most editors/librarians I've > seen are inaccessible. > > 3. An alternative view of events. > > Again, this may be a bit trickier, or outside the scope of James' idea > for qws, but it would be nice to have a way to view events of a track, > in some form of text notation. Something where a-g represent notes, a# > for sharp, bb, bf, or something similar for flat. Perhaps it could look > similar to the gwbasic/basic play statement, known as mml (music macro > language) in japan. I have sources available for one such system, > mml2mid, however the comments are all in Japanese. However, this system > can notate just about any midi event, including control changes, sysex, > meta events, and even some text events like markers and queue points, > that qws doesn't support. > This might make it much easier to do things like, connecting a series > of notes using pitchbend messages, which can be done now, but requires > some event list editor gymnastics. It would also just make another way > of viewing events in the midi possible. > > Again, if you made it this far, take a prize! or something. Thoughts on > these ideas welcome! > > Arthur > > To unsubscribe or change list options, see http://lists.andrelouis.com > > for archived list posts, see http://www.mail- > archive.com/[email protected] > > To unsubscribe or change list options, see http://lists.andrelouis.com > > for archived list posts, see http://www.mail- > archive.com/[email protected] To unsubscribe or change list options, see http://lists.andrelouis.com for archived list posts, see http://www.mail-archive.com/[email protected]
