Troubles getting multiple effects to run on the same pixel string

[Jim Mc]

Hi all,
I'm working on a project for the upcoming holiday season where I want to use MIDI input to light up many parts of a display, and vary the colors based on notes played.
 
I can successfully create ESEQ effects and can get basic functionality from them, and I've tried FSEC ESEQ's, and I can get those to work individually as well.
 
But here's my problem, I want to run multiple effects at once. (Actually, a lot of individual effects at once.)
 
Here's the simple test scenario where I'm trying to get things proved out first:
 
One Raspberry Pi acts as the MIDI unit. It will use the MIDI plug-in to read music notes, and send commands.
The other Raspberry Pi receives commands from the MIDI unit.
Right now for a test scenario, the receiving Raspberry Pi has a string of 50 pixels on the built-in pi-hat on the Raspberry Pi.
 
In XLights, I set up 4 ESEQ's, each lighting a separate submodel of 12 or 13 pixels in a certain color.  (ESEQ1 sets pixels 1-12 (submodel1) Red, ESEQ2 sets pixels 13-25 (Submodel 2) Green, ESEQ3 sets pixels 26-38 (Submodel 3) Blue, ESEQ4 sets pixels 39-50 (Submodel 4) Yellow). All 4 ESEQs are 10 seconds long. The ideal result is that I can start all 4 of them and light the string up fully. Or, I can light up just the individual sections
 
The problem I run into: If I start an ESEQ, and then start another ESEQ, it blanks out the pixels lit up by the first ESEQ. My question: How do I light up the 4 parts of the string independently, without blanking anything out?
 
I tried FSEQ ESEQ's and got the same result (only plays one at a time, and if I start one before the other finishes, it blanks out the pixels in the first ESEQ).
 
Any help would be greatly appreciated!

[Jim Mc]

Hi all, I don't know if I violated a forum rule and didn't get replies, or if this is just something that no one else has any desire to do. Any feedback would be appreciated.

[breese]

I do not believe you can run 2 ESEQ or FSEQ files at the same time on a single controller.
Sounds more like you should be running a normal sequence...
Why the multiple ESEQ files?

[JonD]

X-Lights is going to store all prop information in the sequence, even if some props/submodels are dark.  Not sure it would even work to play two at once, as one sequence would be telling the lights to be dark, and the other trying to turn them on. Which would win if there was a conflict? 

Nothing stopping you from having two individual sequences separate, and then a third sequence with both the first and second combined.  If you wanted them to do different things, you would just need to create a sequence for every variable and only play one sequence at a time.
 

[dkulp]

Separate submodels in xLights will not work as the eseq that is generated is for an entire model.   If you create actual individual models, then the eseq thing would likely work fine.

That said,if you are just trying to turn on or fade something due to a midi event, you likely could use the built in Pixel Overlay effects and not need the eseq's at all.   

[Jim Mc]

Thank you all for the replies! Regarding what I am trying to do: Rather than build a sequence for a group of trees, I was hoping to use the MIDI functionality so that when keys are pressed on a MIDI keyboard, certain parts of those trees light up. So instead of creating a sequence, the display would light up depending on the music (or just keys) played.

It was actually a fun exercise to map 88 keys and 7 octaves across 5 trees so that all the trees would light up, say green, when 4 consecutive C notes were pressed on the keyboard. But my lack of understanding on the ESEQ's was my downfall. I guess I should have tested that first. JonD's explanation makes sense now, thank you for that.

I thought about creating a sequence for the whole display of trees when each key is pressed, but if someone is playing music on that keyboard, it would be overwhelming as any song is played - too chaotic, too fast because normal music's pretty quick.

As a plan B I was working on building a sequence for each individual key, and have some color overlap between keys so everything doesn't change with each key pressed - make the changes more subtle to "slow down" the display. But I think I have to tamp down my aspirations, as normal music moves across the keys and octaves so broadly that it's probably still going to be too chaotic. I'll experiment.

As I was typing this, dkulp also replied, explaining the models (thank you!), and mentioning Pixel Overlay - I've not used that, I'll poke around with it as well.

Thank you very much for your insights. You've helped me a great deal!

[dkulp]

You may not need an ESEQ for each key....   See how I had it configured for my VCS presentation:  



Basically, used a formula to determine which submodel to light up, another formula to determine how bright to light up based on how hard the key was pressed.   I used the "Color Fade" overlay model effect and each press would light up a model for a 1 second fade.   I only had 10 models configured, but you could have a full 88 models if you really wanted to.   

[Jim Mc]

This is great! Thank you, I will be experimenting. Much appreciated!