Effect Engine Hog2 Import

HawthornHawthorn Registered User
Hi,

Is it possible to merge my hog2 effects tables and my effects library into the hog3 ?
Or do I have re-create all of it ? :17:

Thanks

Laurent F

Comments

  • chrisfchrisf Registered User, HES Alumni
    edited March 2006
    I am afraid not. We are able to convert Hog II showfiles to Hog III however effects, macros and programming on custom fixtures does not convert i ma afraid.

    Cheers

    Chris
    FPS/HES
  • HawthornHawthorn Registered User
    edited March 2006
    :eek: Well, I will throw me in the lake nearest :17: ... no effect, no midi... damned :aiwebs_007:
  • chrisfchrisf Registered User, HES Alumni
    edited March 2006
    No midi? i am not sure i understand?

    Cheers

    Chrisf
  • HawthornHawthorn Registered User
    edited March 2006
    Well, just no midi notes to control fader... all the other midi functions are there, it's perfect... But for a show, the guy at keyboards, drum machine and samplers control intensity level of fader through midi notes. And I want to test the hog3 on this show. So Cat West of High End Systems have a solution, creat a comment macro in a cuelist that tells Fader X to crossfade to Y% ... So, no worry, just a work of adaptation.
    except this, the hog3 has really what I wanted to see appearing more than on the hog2
  • jankirchhoffjankirchhoff Registered User
    edited March 2006
    laurent,
    so you need a seperate macro for each intensity level and fader you want to control? sounds not too good to me...
  • HawthornHawthorn Registered User
    edited March 2006
    If midi note don't existe... It's a solution... But Actually it's just some test with the guy at keyboard... But I don't like it... to much macros...
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Hawthorn,

    I couldn't find a bug open for the lack of MIDI note support in Wholehog 3, so I opened up defect #9052.

    Is there anything that you would like to see added or handled differently than it was in Hog 2?

    Thanks.
  • jankirchhoffjankirchhoff Registered User
    edited March 2006
    teerickson wrote:
    Hawthorn,

    Is there anything that you would like to see added or handled differently than it was in Hog 2?

    Thanks.

    MIDI-IN
    Support for MIDI-IN was great on the Hog2, I was able to get the desk connected to most media-control-units I got in touch with that were able to send MIDI. MIDI-notes for fader values were also a nice thing I used every now and then. A possibility to send a fader value with just one MIDI-note instead of sending 2 notes would be great. I've had to build weird setups with a laptop with MIDI-IN and MIDI-OUT to convert MIDI-messages in situations when the sender of the MIDI-Notes needed to be able to control fader intensities without somebody changing cues in the desk - some systems can only send one note for each event.
    Since this function would block a lot of MIDI-notes just for the faders, you should maybe map the control of the faders on a seperate device-id and add an option in the control panel to enable this function since some people might get confused as they are used to have the desk listening to all device-ids by default in the past.

    MIDI-OUT
    I was triggering Arkaos a lot out of my cuelists in the Hog2 to run the video in sync to my show (programming one cuelist for each song). It was a lot of work to type all the notes in the comment-fields. It would be nice if there were some kind of shortcuts to trigger MIDI-Notes. Like "ON8" and "OFF8" instead of typing MSh1/9008FF and MSh1/9108FF in situations when you only have one MIDI-Out device.
    A possibility to see, what notes are triggered within a cuelist and when they are released would also be helpful. I know that some other cuelist on the desk might also send a MIDI-Note, but such a view on only one cuelist would help a lot to find typos and forgotten note-off-messages when you are programming a show that is running off of one list.

    Jan
  • HawthornHawthorn Registered User
    edited March 2006
    Hello,
    For midi-in… it’s really like Jan.
    On hog2 I use midi-notes to control fader values, and actually, I have a laptop to transform a solo midi note in a ctrl and a midi note. So having juste one note to control the fader value could be great. (Jan, happy to see that I am not the only one to do it). And like on the hog2, to be able to control all the fader even without the wings and the extensions.
    Well, it is the first striking thing which comes to my mind
    I don’t really use the midi-out.
  • pbeasleypbeasley Registered User
    edited March 2006
    Tom,
    For MIDI OUt you should have something in the logs from a long time ago where I asked to have something akin to a MIDI Notes fixture type, something that could actually be "cued". Is that still in there?
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Jan & Hawthorn,

    I've added your comments to bug #9052.

    Thanks for your input.
  • jankirchhoffjankirchhoff Registered User
    edited March 2006
    hmm.. being able to have a "dummy midi-note lamp" to control midi-notes like a gobo-wheel sound like an interesting idea...

    But how should that work in detail? We have 127 notes and each has a velocity... a fixture with 127 channels?
    Or a fixture with just one channel: velocity. You could patch as many fixtures as midi-notes are needed. that sounds better!
    Might be a very nice feature when you are triggering external hardware/prorams like Arkaos. As I think back of typing all those notes in comment boxes, a simple "901@127" would have saved a lot of time
    Jan
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Paul,

    I really like your idea of a cueable MIDI message fixture. I'm not seeing a bug currently open, so I want to get some more details from you and then I'll open a new feature request.

    I assume we'd want to add 2 fixtures. One to send MIDI continuous controller data and one to send MIDI notes.

    Continuous controllers send 2 pieces of information. The first is the Controller Number and the second is the Value. I think one possible implementation would be to have the controller number on one wheel and the value on another. We would also want a slot for transmit enable / disable. If the value changes and transmit is enabled, the value is transmitted. If transmit changes from disabled to enabled, the current value would be transmitted.

    MIDI notes are a bit more involved. There are both note-on and note-off messages. Note-on messages contain the MIDI channel number, the key number, and the velocity. Can you give me an idea of what information you need for the devices you're working with? I'm not sure how much of this we need to implement and I can see things getting complex pretty quickly.

    Let me know what you think of this. I'm sure we can come up with something that would work.

    Thanks.
  • jankirchhoffjankirchhoff Registered User
    edited March 2006
    @tom
    To keep it simple but not loose any functionality:
    define that 0 is not off, 1 to 128 is note on and the velocity.
    When you "patch" the fixture, you define what note (key) and what MIDI channel it is. Once it's patched, the behaviour should be just like a desk channel as I wrote earlier: 901@0 is note off, 901@56 is not on with a velocity of 55.

    If I needed 70 keys I'd just patch 70 of those "MIDI note fixtures" to keys 0 to 69 and trigger my visuals this way - can't think of anything easier, it would just be perfect for Arkaos.
    Other people need to give input on other software...

    Jan
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Jan,

    I was thinking it would be easiest to come up with a fixture that wouldn't have to be patched. This would keep us from having to completely re-work the patch screen to add a "MIDI Universe" patch system.

    Being able to cue the triggering of MIDI events makes logical sense to me. Having to patch these MIDI fixtures seems a bit confusing. We want to make sure that we implement features in a way that is logical and easy for users to understand.

    Feel free to disagree.
  • jankirchhoffjankirchhoff Registered User
    edited March 2006
    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...

    Jan
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Jan,

    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.

    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.
  • jankirchhoffjankirchhoff Registered User
    edited March 2006
    teerickson wrote:
    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.
    teerickson wrote:
    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:

    Jan
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Jan,

    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.
  • ahelgorahelgor Registered User
    edited March 2006
    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?
  • pbeasleypbeasley Registered User
    edited March 2006
    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.
  • HawthornHawthorn Registered User
    edited March 2006
    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...
  • HawthornHawthorn Registered User
    edited March 2006
    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 ...
  • quinnquinn Registered User
    edited March 2006
    tom,

    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.
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Quinn,

    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.
  • quinnquinn Registered User
    edited March 2006
    they're the same format... the status byte gets a different value, and data2 is just ignored.

    but i get the usability thang. don't agree but i get it.

    i'd love for the fixture builder to get a midi Kind category with a byte-spitter-outer along with the "proper" functions.
Sign In or Register to comment.