Okay, i know Andy had one particular use case in mind when he created this beast, but that doesn’t mean we can’t use it to do something else.
In my case i have a very particular application for which YammieQ is proving to be a life saver.
I’m working on a very challenging project right now that is pretty heavily under NDA because the actual product has not been released yet, but i can at least say this much. It involves the use of 360 VR cameras in a live multi camera environment with 3D 5.1 multi-point source audio. That’s about as specific as i can get.
Anyway, because this is a live environment, there is a strong preference to do all the audio routing using very reliable and proven hardware audio consoles. However, the task is to be able to transition between multiple 5.1 outputs streams [6 discrete channels] with a predetermined and adjustable fade rate between those outputs streams. Also, a straight linear crossfade between the audio streams is not acceptable as this causes a loss of energy and perceived volume at the cross point. No, it needs to be a logarithmic crossfade.
Oh and did i mention it needs to be externally triggered from a video switcher. As well as locally from the console. While keeping full console functionality available to create relative level changes between 5.1 outputs on an as needed basis. and be able to monitor at any point in the signal chain.
Anyway, my trial run was done with GPIO on a QL5 using scene changes and lots of clever routing. But this provided none of the necessary crossfading. all changes were hard cuts for complicated routing reasons.
Enter YammieQ.
I’m in the process of building cue files now using YammieQ so that i can trigger any number of crossfade cues between various sources as well as adjust the fade rates. I’m sure i’m gonna run into some issues as i go, so i’ll keep you posted on that.
In the meantime i also need to read up on MIDICPU so i can up my GPIO count beyond the 5 on the QL5. I could need as many as 16 eventually.
Just thought i’d share an out of the box application for this nifty swifty software.
Note that you can easily edit any the delay, value and channel fields of the parameter messages after the fact. So to get a logarithmic fade you could record a manual fade of a control, then go in and edit the fields, say making all the delay times the same and then changing the value field so that you get the logarithmic fade you’re looking for. Tell me the db/sec you’re looking for and I can get you the values needed if that helps.
I will definitely get with you WRT to values as that will undoubtedly save me a huge amount of time.
Also, i haven’t dived completely into this but i’m curious about one thing. For my scenario i need a trigger/GPIO to trigger a particular set of fader/knob moves. Then when a different trigger/GPIO happens i would need the previous cue to fade while the next goes up. There are potentially a dozen or more of these triggers that can happen at any time and in any order. How do i make a cue list that includes “get rid of the other thing you did and now do this new thing”. Mostly it’s the “get rid of the existing thing” part that i’m unsure how to implement. This is probably an easy question for someone like you, which is why i’m asking first before i figure it out myself.
I don’t think so. Let me explain what i want to do more simply. For simplicities sake let’s say i’ve got 5 DCAs and i want to have 5 triggers each of which cause 1 of those DCAs to go to unity while simultaneously turning down whatever DCA is currently AT unity. So basically there will always only be 1 DCA up and the other 4 will be down.
If there were no crossfade between DCAs i could simply have each cue be the target DCA up and all the rest down. But since there IS a crossfade, i’m not exactly sure how to make this happen since if i simply fade up my target DCA while simultaneously fading DOWN my other 4 DCAs, the 3 that were already down will jump up to just below unity before they all fade down to zero.
The trick is how to have the cue know which DCA it needs to turn down when it could be any of the other 4 given that the triggers can happen in any random order.
Maybe if a trigger could cause the first cue in the cuelist to go [send DCA 1 to unity] and then pause in it’s cue list until another trigger happens. then when another trigger fires, the first cue list would continue to it’s SECOND cue which would be the cue to return DCA 1 to zero. Of course that second trigger would also cause one of the other DCAs to go to unity and pause as before.
I’m not sure if your cue lists contain this kind of functionality or if it could be added. Or if there is another easier better way to do this.
My method for doing this before involved using scenes of the QL5 and then simply setting a fade time. This works fine so long as it’s only faders that move [i may well need it to be other parameters]. However, it does have the problem of volume drop off because of the linear curve. That’s the issue ultimately i’m trying to solve here.
I’ve attached a file for the CL5 (which will work on the QL/CL) that demonstrates a way to possibly achieve what you’re looking for.
Load it up, and in run mode, and with YammieQ “focused” (meaning it’s the program that will receive keystrokes), on your computer keyboard press the number 1 (with the ! above it). This should take Channel 1 to 0db.
Press 2 on your computer keyboard, and it should fade Ch 1 while putting channel 2 to 0db. Then press Key 1 again, and see if the opposite happens.
If it works, you’ll have to copy the programming to make the other channels work, and I’ll be happy to explain how it works. If it doesn’t, let me know. I’m not in front of a CL5 console to test it unfortunately.
Excellent. I’ll be going into the shop in the next couple days and i can test this on a console. I’ve looked at the programming and have a general idea of what you’re doing. I’ll just have to see if it works.
What you may not be familiar with is the “Request” commands that are in there. They poll the console for a parameter’s value and the console returns the value of that parameter, as if you’d actually moved that control manually. Also, I’m using a local trigger which is different than a global, where it only acts on a “loaded” cuestack.
There’s also many shortcuts to creating these sorts of YammieQ setups once you are familiar with the editing functions in the program.
Let me know what you find. I won’t be surprised if it doesn’t work quite as expected - the Yamaha editors unfortunately do not respond to request messages so I can’t test it without an actual console connected.
Very cool stuff. i figured there was a way to do these things.
i’m going in to the shop next tuesday and i’ll be able to try this out with an actual desk. Stupid question… I can communicate from a QL/CL to the YammieQ via ethernet? I don’t need a Midi interface?
Not stupid at all. Yes, you do not need a MIDI interface with the CL/QL. You can even connect the console to a wireless router and control it wirelessly.
You don’t actually need a MIDI interface to use YammieQ with ANY Yamaha digital console. Well, one with MIDI connectors, anyway… In reality all Yamaha communication is MIDI, it’s just different ways to transport it. http://www.checkcheckonetwo.com/forum/showthread.php?1507-YammieQ-Instructions-(Windows)&p=6948&viewfull=1#post6948
Okay, sitting at a QL1 trying to use the test setup and sadly it doesn’t work. basically hitting the 1 key brings fader 1 up and hitting the 2 key brings the fader 2 up. no other functionality.
There is a red ! warning beside the 3rd trigger on the file which i believe is the trigger that would read fader position and cause faders to go down. There’s no dialog written on the warning, so i don’t know what it’s saying.
i also notice that the third trigger has no cues below when i highlight it. that’s probably as it should be, but i thought i’d mention it.
i’m gonna peruse the tutorials here to see if i can get a better understanding of follow cues and the like.
If this works, you’ll need to add the other 3 faders to test it fully. Also, there needs to be something in place to stop the faders from fading on their own if you set them to 0 manually. There are several ways to do this, but let’s get the basics working first.
excellent. i’ll try that on Friday when i get back to the shop.
thanks.
btw, i tested YammieQ using Parallels and the Ethernet Lan connection and it worked perfectly. I was also able to add a second Ethernet connection with a Thunderbolt to Ethernet adapter and use that to run Dante applications via the Mac OSX with absolutely no issues. Everything worked simultaneously with no issues. So that’s a cool thing.
I’m glad it worked. I just tested it again, and realized that I had the numbers off by 1 in the 2nd trigger as well. Fixed it and replaced the file I uploaded previously.
Ok, here’s how it works…
Trigger 1 & 2 are basically the same. They are immediate triggers so only the cues in that cue list that are marked “I” (Immediate) will fire when that trigger is hit.
The trigger in this case is the number 1 and the number 2 on your computer keyboard.
The immediate triggers fire the immediate cue (1st one in the list) and they just raise fader 1 and fader 2 (respectively) to 0db. You can see that when you open that cue that this is what the first parameter message in that list does. The next 4 parameter messages are “request” messages, asking the Yamaha what the value of the other 4 faders are. When the console receives these messages, it sends back to YammieQ the value of the fader position. (0db = value 823, btw).
The other cues under each of the 1st cue are value cues, which will get fired whenever the value of the parameter in trigger #3 is matched.
Trigger #3 is triggered by the value of any fader being set to 0db (823). So, if any of the other 4 faders are at 0db, this trigger will hit, firing the cue matching the channel (or channel-1 in this case) in the Mode field.
What this means is if any fader other than the one just set to 0db is already at 0db, it will hit trigger #3, and the corresponding cue will fire, which fades that channel down.
Trigger #3 is a “Local” trigger which means that it doesn’t have it’s own cue list, it acts on whatever cue list is currently loaded. So pressing trigger 1 or 2 will load that particular cue list, but trigger #3 will not load a new cue list, it will just call the cues in the currently loaded list.
If you watch what triggers and cues are highlighted as you run this setup, it’s easier to see how the logic works. Notice that the trigger that’s currently loaded is marked with the > icon to it’s left, but the trigger that has been hit gets selected (highlighted in blue). The 2 can be different. Also whichever cue(s) get(s) fired will be selected as well.
I’m going to try to duplicate this across the multiple channels myself as a test to make sure i totally understand what’s going on here. Then the next step is to make the changes not be fader changes but in fact multiple mixbuss sends that change simultaneously. So that’ll be a fun way to multiply the work.
Then i need to do some experiments with the console to set fade rates to achieve my final goal. Still i’m stoked that this is going to do the fairly complicated and unusual thing that i need to do.
Thanks for the help Andy. I’ll keep you posted on my progress…
