Am Mittwoch, 30. Mai 2007 schrieb Paul Coccoli: No. _All_ hardware uses 0-15 or 0x00 to 0x0F. Just look at the raw midi-stream. Most hardware translates that for the user to 1-16 and this could also be possible for applications. But inside the program 0-15 will be used again at least on the lowest level of midi-io. I think if developers start to do a two-way thinking about gui on one hand and rest of the application on the other hand, they might start to design guis for users (instead of guis for programmers) which includes midi-channels starting with 1. But very often I find myself exposing to much internals to the user... Arnold -- visit http://www.arnoldarts.de/ --- Hi, I am a .signature virus. Please copy me into your ~/.signature and send me to all your contacts. After a month or so log in as root and do a rm / -rf. Or ask your administrator to do so...

Hi All, So, lets see, we are going to have 16 midi channels but people have to select them from 0 to 15? How about sampling rates - if I want 44100 samples per second am I going to have to give the value of 44099 to cater for the zeroth sample? How about when I select "-interleave 4" channels of sound; is that quadraphonic or 5 channel surroundsound? How about the "10 items or less queue" at the supermarket? People understand this, however if you really want to count from zero then you could try and justify being in the queue with 11 items and get into one massive argument with the person behind you. The honest truth is who really gives a fig about the MIDI specification? It has 16 channels, and in that supermarket queue they are numbers channels 1 to channels 16. Their is absolutely no consistency in an application that demands some parameters as cardinal and demands other parameters as ordinal values. Just out of interest, on a related topic, the issue here is one of understanding the specifics of each application/softsynth and the fact that some use different numbering, and also regarding the overall usability of the different Unix versionn. I would say that for people who get into using the apps then the channel numbering is not important - they will find the differences. For people, on the other hand, who just want to try the synths as easily as possible then selecting channels is a great pain in the butt, so, MIDI addressed this with the OMNI mode where your synth, unless otherwise specified, should ignore the MIDI channel and respond to everything, and even specified that this be the default mode of operation unless otherwise selected. Perhaps it would be wise to ask the developers of these synths to be in OMNI mode unless a midi channel is specified, and in the latter case the user should have a better idea of what is going on. The reason I ask regards Bristol, it does not operate in OMNI mode but I have debated whether to implement it (it has always numbers MIDI channels from '1' since nothing else really makes much sense). That kind of depends on requirements, however it also occured to me that unless otherwise specified then the ALSA seq library should also default to 'OMNI' mode. This follows a recent question posted here as to why somebodies USB keyboard would not connect per default to their soft synths, leaving this new user to dig around to find something called aconnect that accepted some wierd and rather unintelligible numbers just to test a couple of applications with their master keyboard. If all the synths acted in OMNI mode and the ALSA sequencer library (and other other MIDI libraries) acted in OMNI (everything source connected to every sink, unless otherwise specified) then it would be an easier system for a new user, and would not be any more difficult for an experienced user. Unix historically does nothing unless you b) tell it to a) know how to tell That is kind of broken unless you 2) know how to fix it 1) like things being difficult to start with It shouldn't be so difficult. Also, the remark about hardware using channel number 1 is actually correct: their reference here was to hard synths rather than soft synths. The hardware in this case is not the chip set or the protocol specification but rather the synths that implement MIDI allowed the player to select channels numbered from 1. Once again, who cares a fig about what the protocol specifies, or even what the hardware does - if I have 16 channels then as a user I expect them to be numbered up to 16. If people want anything else then there should be another option called -midichannelforpedants Regards, N. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Nice. Just put that in your manual and see if it makes sense - get your ruler out and measure the number of channels? You have lost the point here: how is a user really supposed to know that MIDI channels should be counted from 1 or from 0? Are you expecting a user to understand that MIDI reserves 4 bits for channel selection therefore to reach 16 they must have been counted from zero. That is a stupid assumption - if more bits were available then even as a programmer I could well understand that channel zero be reserved to indicate 'isolated' and still reach channel 16, which to me would seem quite reasonable. Why is that wrong? That would sound pretty much lilke a MIDI mixer function, and why should that not be done by default? Why do you think this 'trick' breaks down (it isn't a trick BTW)? MOTU has made millions selling hardware to do just this (and admittedly more). In fact MIDI was build this was to allow for layering between different synths allocated to the same channel - far from breaking down this actually enriches the capabilities of my installation. You are well of the mark my friend. Just imagine it were different - you just connect your MIDI master keyboard to your synth and it works. Amazing. Just imagine that. Rather than having to check whether the master keyboard and synth are on the same channel and that the synth and master keyboard have the same concept of channel numbering. Sorry mate, OMNI was designed to allow products to interoperate with minimal intervention but more on this below - attach the cable and they work due to defaulting to OMNI, why is this not done with Unix softsynths? Agreed, but this looks again like you have missed the point. What does this proposal have to do with dumbing down? It has not proposed simplifying anything, that would have been dumbing down. On the contrary the proposal is to have a more considerate set of defaults. As stated in my submit, that you seem to have read rather lightly, this does not affect the complexities required of a user - in the current situation the default is no connnection and you have to build the ones you want. In the proposed case you would need to use the MIDI connection tools to break the default OMIN connection before building new specific ones that you require. If it makes you feel any more 'highbrow' it actually makes things more difficult for you as a knowledgable user, which seems to be what you are after. In addition to that it makes things almost infinately simpler for someone who does not want to read 50 README files for different applications built by pedantic developers. Regards, N. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Last time I read the specification was quite to the point on this issue, stating that channel-1 is sent with a value of '0' in the channel nibble and channel-16 was sent with an 'F' in this same field. It was put in the specification to avoid this ambiguity since the authors in their wisdom realised musicians may well not understand hexadecimal numbering and better have implementors avoid potential conflicts. As such channels were numbers 1 to 16 and '-chan 0' is basically broken. You could argue that '-chan 0x00' is a different issue and diverse documents do refer to hex notation as being separate from channel numbering. The same authors also went to the point of specifying Omni to avoid other ambiguities and complexities that a less experience user might well be helped to avoid. Either we are using MIDI and may well want to adhere to its design goals, or perhaps we should not be using it. There are arguments to have it redefined, not least the fact that the MMA now demand cash for copies of the specs. I'll drink to that. N. _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/

Hi Fons, It looks like preaching to the converted I admit. Quite. However the person that wants the simplest case is the one that does not want to spend time reading all the different readme files - this was exactly the point of the submit to this list regarding the complexity of just testing all these softsynths. If the default allows this connectivity which would be very much in the mood of the original MIDI specification, as opposed allowing no connections at all, then another user is catered for and the design is in line with the MIDI specification. Then you should also know how to break all the existing connections. Put it this way, if you have worked out an easy way to setup all these connections then you should have been able to fid a similarly easy way to disable any default MIDI mixed connections that you did not want. On the other hand if you don't know how to build all your ten connections then you probably don't even know how to build one and you are in for a world of hurt just getting a sound out of a softsynth. That is totally counterproductive. Unless the default were to connect things together..... I am not talking about making this work easier, however it is not making it that much harder for an experienced user either. This issue here is that when you know how do to something it is easy, when you don't know how to it is hard, and the default should be to reduce complexity. Then as a capable user you should have started the whole connection toolkit without the defaults and just built your connections. Listen up friend, if you are in charge of a PA system and even trust that the default connection setup is "none" then you are in a dangerous position - you should make sure of it first by breaking connections before bring things online. You are again making assumptions and these ones might end up blowing your speakers for you. Oh, yeah, deja vu. That is MIDI Thru and was intended to be kept that way. I don't know of many MIDI devices that will echo In to Out as a default since the default for this functionality is the Thru link - again, the capable user may configure this if their device supports it, but then they should know about the implications anyway. Interestingly enough, from your last submit to this list you refered to this very function as a 'trick' that if used would break things, now you are quoting the same MIDI mixing function (in this case mixing In with whatever you play on this synth) as if it were a standard feature which is kind of contradicting yourself, no? Back to my original point, the MIDI specification stated that a system should start up in OMNI mode unless otherwise specified such that any keyboard could drive any sound module on power up since channel numbers would not be considered. A capable user could change this configuration, but that is their choice. My proposal remains true to the mood of the original specification, here suggesting that a MIDI seq interface should consider being OMNI as well and allow things to be connected together by default. Regards, N. _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

The proposal remains then that this file should contain something reminiscent of OMNI as that is a reflection of the goals of MIDI. As you state, this is stuff that a novice does not want to know about and as such the system per default should do exactly what a novice wants: a connection. The content for any other user who is savvy of their applications should be whatever they want to put in there, but why are we expecting the novice to have to be faced with this very stuff that you admit should not be their business - simply because the default _forces_ them to be confronted with it? If you think the novice should not be faced with these details then the default should provide for that which the novice needs. Regards, N. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Sean Bolton &lt;musound(a)jps.net&gt; writes: Do you know zynjacku? It is like ghostess but for lv2. I was thinking about adding DSSI support too but I wanted to avoid duplication. If you are going to rewrite ghostess anyway I'd be more than happy if we can make zynjacku both lv2 *and* dssi host. http://home.gna.org/zynjacku/ -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>