Hmm... I do disagree ;) What I would always do is patch fixture #901 to note 1 - this way it stays logical. If you leave out the whole progress of patching, you'd have to add 2 parameters to the fixture: device id and MIDI note. Imagine I need 50 notes (which is not much for Arkaos and other programs like that), this way I'd have to manually configure all 50 fixtures and set every single note with the parameter wheels?! That would be confusing and time consuming. You could hit the wrong wheel by accident during programming and suddenly everything is doing weird things because your first fixture is now sending note 2 instead of 1.. What happens when fixture 2 is changed? Does it override the first one? It's easier and definitely safer to take care of this configuration somewhere before you start programming - that would be in the patch-window...
If you are patching to a single note, then you would need to have 16 "universes" for your 16 channels (plus one for omni) and each universe would require 88 "addresses" for each of the notes.
There might also be cases where it would make sense to have multiple fixtures controlling the same MIDI note. I might want to have a fixture for each of my individual notes and one fixture that controls a subgroup of those notes.
[quote=teerickson] How would you want the patch interface to work?
If you are patching to a single note, then you would need to have 16 "universes" for your 16 channels (plus one for omni) and each universe would require 88 "addresses" for each of the notes.
That's about how I thought it could be. But as far as I remember, it's 127 notes? but maybe I'm wrong... The patching would just be as patching dmx-fixtures. Just that a different window will pop up to let you choose the device-id instead of a dmx-universe. Patching 50 channels in a row on the same device-id would be the same as patching 50 desk channels in a row... done in a few seconds.
[quote=teerickson] There might also be cases where it would make sense to have multiple fixtures controlling the same MIDI note. I might want to have a fixture for each of my individual notes and one fixture that controls a subgroup of those notes.
When I want to change multiple notes at once, I make a group like I do with any lamp and change all lamps (MIDI notes) at the same time?! That would be my way of doing it. And MIDI note "behaviour" would perfectly match the way lamps behave... and when you want one fixture to control multiple notes, just patch it that way as you would do with a desk channel that is supposed to control a bunch of dimmer channels.
Isn't the great idea of the Wholehog that everything behaves the same, just as you would expect it? Why make a MIDI fixture behave different than a desk channel?
I don't get the point where the other approach could be more useful compared to a "simple" 1-channel-midi fixture that needs to be patched. Please help me out when I'm wrong, maybe I'm already stuck in my idea... ;) But' I'll go to bed now, it's close to 1am here in Germany... Maybe your approach makes sense to me tomorrow after some coffee :06:
Your comments make sense. I think you're right, as well. I was thinking of a full-size keyboard having 88 notes, but I think I remember now that the implementation offers 128 values for notes.
I'll sleep on this one as well. We can see if anyone else wants to jump in here and offer an opinion.
Hope i'm not sounding like i'm negative to the idea here, couse i'm not, but i'm just a bit qurious about how many that will actually need this?(and it seems like a big undertake to implement) correct me if i'm wrong, but I can't say i know of many products/softwares in the "professional" end of the scale that is getting controlled by midinotes/cc.. of cource we got MSC, but thats another case.. I sertainly can see your point about arkaos as an example..but you can control arkaos with dmx also(actually a lot better)
Don't wan't to put a break on this thread, but i'm just qurious about how many that will actually need, or use this if it was there?
Jan and Tom are thinking along the same lines I was when I first brouhgt this up years ago.
from June, 2002 What about MIDI notes as a fixture type. This would include being able to do Note on/off and velocity in playback of cues. If a fader/list is released, the corresponding note off commands would be sent. In a HogII world, I would see this as choosing the number of notes you wanted to be able to send, and then patching Fixture MIDI(x) to Note(Y), fixture MIDI(x+1) to Note(Z), etc.
Well, I arrive later in the discution, but the possibility of patch a fixture with midi note like dmx channel, could save much time and programming. That would also strongly decrease my number of cuelist. To be able to patch more than one MIDI note on only one fixture would be perfect. With the note 1 I control My six lamp, and with the note 2 to 7 I control each lamp separately. So the second lamp have the note 1 and 3. With the 128 MIDI notes, you can do a lot of things. With this control, to command the fader intensity with a MIDI note becomes almost useless for me. If I want to control the intensity, I use directly the MIDI "patch"... Well could be great...
Well, and the best of the best is having a MIDI note in and a MIDI note out (the same.. not two diffrent patch). When I use the Hog for theatrical application, I use some motorised fader to control desk Channel, and with a return of information, the fader move with the intensity of the fixture. The operator can increase the intensity of just one fixture if his cue is not really like he want. If the hog send directly the midi note with the dmx value, I win lot of time of programmation ...
i'm totally more interested in controllers than notes, but having two fixture types would leave me pretty screwed when i want to send a program change.
i think a fixture with four channels (message type + channel, data, data) would not only be way flexible, but would save you from gutting patch to implement midi. that's what edit fixtures is for.
Program Change messages have a different format than the note and continuous controller messages that we have been discussing.
I'm inclined to avoid getting into a situation where we have multiple non-descript "data" parameters that are tough to identify on wheelsets and in the output window. I think it would be clearer to add fixtures for each type of message that have clearly defined parameters for the appropriate options.
I'd love to hear everyone's opinions about this along with more specific examples of how you want to use this functionality to help us decide on a strategy for implementation.
