Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

‘Misfires’ when running with midi. #781

Open
The-Torrent opened this issue Apr 27, 2019 · 10 comments

Comments

Projects
None yet
2 participants
@The-Torrent
Copy link

commented Apr 27, 2019

The project is you press a key, an optoisolation circuit translates the midi signal to the arduino then midi library and serial library, then the corresponding key lights up do basically u press a key on the piano the key light turns on.

Due to disabled interrupts I’m guessing the issue is, when running the program, there are random ‘misfires’. Is there a way to fix this? Or a method of enabling interrupts?

@focalintent

This comment has been minimized.

Copy link
Member

commented Apr 27, 2019

I'd need a lot more information to be able to guess at what's going on (also - this is the kind of question that's far better to ask in the community at http://fastled.io/r/ - as you'll have the advantage of getting feedback/suggestions from a variety of people who've solved this - I try to keep GitHub issues to more specific bug reports, feature requests, etc...)

For a specific way to fix this, I'd need to know more about the hardware/library you're using for getting midi data - but my guess is that because of the way midi continuously streams data, you'd need hardware that could handle buffering data until a library read it - I'm not sure what options there are for midi hardware that works with Arduino on that front.

If you want to be able to enable interrupts so that you could do this - you could run on one of the hardware platforms that allows interrupts to remain enabled while writing out clockless led data - e.g. the teensy 3.x or the esp32 or esp8266 platforms. In those cases, though, you'd have to be sure that the libraries you were using had interrupts handlers that were fast enough to not cause writing led frame data to reset.

Another option would be to switch to LEDs, like the APA102, that use both a clock and a data line, and since they aren't constrained by tight timing requirements, don't care whether interrupts are enabled or not.

(And I'm fairly certain there's at least a couple of folks in the community who have done pretty much exactly what you're describing wanting to do - or at least close enough (ie. midi data to led data))

@The-Torrent

This comment has been minimized.

Copy link
Author

commented Apr 27, 2019

I'd need a lot more information to be able to guess at what's going on (also - this is the kind of question that's far better to ask in the community at http://fastled.io/r/ - as you'll have the advantage of getting feedback/suggestions from a variety of people who've solved this - I try to keep GitHub issues to more specific bug reports, feature requests, etc...)

For a specific way to fix this, I'd need to know more about the hardware/library you're using for getting midi data - but my guess is that because of the way midi continuously streams data, you'd need hardware that could handle buffering data until a library read it - I'm not sure what options there are for midi hardware that works with Arduino on that front.

If you want to be able to enable interrupts so that you could do this - you could run on one of the hardware platforms that allows interrupts to remain enabled while writing out clockless led data - e.g. the teensy 3.x or the esp32 or esp8266 platforms. In those cases, though, you'd have to be sure that the libraries you were using had interrupts handlers that were fast enough to not cause writing led frame data to reset.

Another option would be to switch to LEDs, like the APA102, that use both a clock and a data line, and since they aren't constrained by tight timing requirements, don't care whether interrupts are enabled or not.

(And I'm fairly certain there's at least a couple of folks in the community who have done pretty much exactly what you're describing wanting to do - or at least close enough (ie. midi data to led data))

So the circuit is just midi into an optoisolation circuit into arduino. Libraries are:
#include <MIDI.h>
#include "FastLED.h"
#include <AltSoftSerial.h>

I’ve been told a faster board will also fix this. Any suggestions? All I need is a uno with a higher clock speed, was told to go due but they don’t make that anymore.

Apa102 will involve me writing code which I can’t do I’m guessing as it’s 2 inputs. it’s also an investment so I need to be 100% it will fix it if I am to buy that.

There are people in the community but a lot of them are so closed up chances are more will try to sabotage than help. I’m know it’s bad but it’s the truth the piano-electronics community is extremely toxic as I have found out.

@focalintent

This comment has been minimized.

Copy link
Member

commented Apr 27, 2019

Ah - ok, so it's basically just using a serial connection - wasn't sure if you were using something that would buffer or otherwise decode midi data.

Switching from WS2812 to APA102 in a FastLED app is as simple as going from:

   // WS2812 leds on pin 8
   FastLED.addLeds<WS2812, 8>(leds, NUM_LEDS);

to

  // APA 102 with data on pin 8 and clock on pin 9
  FastLED.addLeds<APA102, 8,9>(leds, NUM_LEDS);

APA102 data is written out using the SPI protocol (short short version - the bit value of the data line is read when the clock line toggles between high and low - no timing involved (though usually there is a fastest speed you can run the clockline at for a chipset)) - so there's no impact from interrupts (either handling the interrupts possibly interrupting frames, or otherwise needing to disable interrupts).

As far as a faster board - yes, the due would've worked (it's a 32-bit ARM based platform as opposed to the uno's 8-bit AVR based platform - also the due ran at an 84Mhz clock vs. the uno's 16Mhz clock). Personally I use the teensy (https://www.adafruit.com/product/2756 or https://www.adafruit.com/product/3266) in a lot of my projects. There's a variety of options out there - is there any particular reason you want to stick with the Arduino Uno?

And, I can't speak for the piano-electronics community, but the FastLED community does a fantastic job of helping each other out on a variety of things (and some folks who used to be newbies to this stuff when they first started hanging out in the community are now among the people who are quite helpful in answering questions and such!) - and I have never seen an instance in the FastLED community (either on g+ or on reddit since we moved over there) where someone was sabotaging someone else in the answers they were giving.

@The-Torrent

This comment has been minimized.

Copy link
Author

commented Apr 27, 2019

Ah - ok, so it's basically just using a serial connection - wasn't sure if you were using something that would buffer or otherwise decode midi data.

Switching from WS2812 to APA102 in a FastLED app is as simple as going from:

   // WS2812 leds on pin 8
   FastLED.addLeds<WS2812, 8>(leds, NUM_LEDS);

to

  // APA 102 with data on pin 8 and clock on pin 9
  FastLED.addLeds<APA102, 8,9>(leds, NUM_LEDS);

APA102 data is written out using the SPI protocol (short short version - the bit value of the data line is read when the clock line toggles between high and low - no timing involved (though usually there is a fastest speed you can run the clockline at for a chipset)) - so there's no impact from interrupts (either handling the interrupts possibly interrupting frames, or otherwise needing to disable interrupts).

As far as a faster board - yes, the due would've worked (it's a 32-bit ARM based platform as opposed to the uno's 8-bit AVR based platform - also the due ran at an 84Mhz clock vs. the uno's 16Mhz clock). Personally I use the teensy (https://www.adafruit.com/product/2756 or https://www.adafruit.com/product/3266) in a lot of my projects. There's a variety of options out there - is there any particular reason you want to stick with the Arduino Uno?

And, I can't speak for the piano-electronics community, but the FastLED community does a fantastic job of helping each other out on a variety of things (and some folks who used to be newbies to this stuff when they first started hanging out in the community are now among the people who are quite helpful in answering questions and such!) - and I have never seen an instance in the FastLED community (either on g+ or on reddit since we moved over there) where someone was sabotaging someone else in the answers they were giving.

I stick to uno because that’s all I’ve ever used I’m still very new to this.

Is using the apa102 enough or do I need a faster board also? Vice versa.

@The-Torrent

This comment has been minimized.

Copy link
Author

commented Apr 28, 2019

This is what my friend just told me

Might, but you would also need a library that uses that speed to not lock up the uC while sending out the NeoPixel data. Which isn't all that easy. Or by using DMA for example.

So he’s telling me fastled will not work at all because the timing will lock up the uC? Can you confirm. I don’t actually understand what he just said

@focalintent

This comment has been minimized.

Copy link
Member

commented Apr 28, 2019

So - your friend is somewhat, but not entirely correct. FastLED on the teensy 3.x, for example, allows interrupts to be handled while writing out WS2812 data but enabling the interrupts for a brief period after writing each bit of led data, which allows them to be handled - as long as those interrupt handlers can run in under 50µs, then FastLED will be able to continue writing out the rest of the frame. (Yes, it wasn't easy to do - but also yes, FastLED does it on as many platforms as it can - unfortunately the UNO is one of those platforms where the hardware is just too slow to be able to do it).

In addition, if you're using one of the teensy 3.x platforms, you could also use the OctoWS2811 driver/library for parallel output which has the benefit of using DMA to drive output - which also doesn't disable interrupts (https://github.com/FastLED/FastLED/wiki/Parallel-Output)

I'd probably need to see more of the code that you're writing/trying to use to give you more detailed advice at this point.

(I know of multiple folks, however, who have successfully used FastLED for projects like this - so I know it can be done)

@The-Torrent

This comment has been minimized.

Copy link
Author

commented Apr 28, 2019

So - your friend is somewhat, but not entirely correct. FastLED on the teensy 3.x, for example, allows interrupts to be handled while writing out WS2812 data but enabling the interrupts for a brief period after writing each bit of led data, which allows them to be handled - as long as those interrupt handlers can run in under 50µs, then FastLED will be able to continue writing out the rest of the frame. (Yes, it wasn't easy to do - but also yes, FastLED does it on as many platforms as it can - unfortunately the UNO is one of those platforms where the hardware is just too slow to be able to do it).

In addition, if you're using one of the teensy 3.x platforms, you could also use the OctoWS2811 driver/library for parallel output which has the benefit of using DMA to drive output - which also doesn't disable interrupts (https://github.com/FastLED/FastLED/wiki/Parallel-Output)

I'd probably need to see more of the code that you're writing/trying to use to give you more detailed advice at this point.

(I know of multiple folks, however, who have successfully used FastLED for projects like this - so I know it can be done)

Is there any chance I can talk to you or one of those people over discord? As this issue has been resolved for the most part however I personally have further questions. Discord The Torrent#5588

So using apa102’s alone won’t fix it? Hmm...

Also would using a Chinese due clone or something be good enough? As I have an enclosure built for the uno which is another reason I do want to stick to it. (And the due would fit the enclosure).

@The-Torrent

This comment has been minimized.

Copy link
Author

commented Apr 28, 2019

Also a reason I don’t want to move of the uno is because I know this can work on a uno has I know people in the piano community who have managed it however how is what I’m trying to find out.

@focalintent

This comment has been minimized.

Copy link
Member

commented Apr 28, 2019

Again, apa102 should fix it because it doesn’t block interrupts - if you want to talk to folks in the FastLED community to see how they’ve done this - I’d say post here and ask - http://FastLED.io/r

(Unfortunately I’m doing a lot of project juggling and running around right now so this week is a terrible time for me to jump on a chat)

@The-Torrent

This comment has been minimized.

Copy link
Author

commented May 5, 2019

Again, apa102 should fix it because it doesn’t block interrupts - if you want to talk to folks in the FastLED community to see how they’ve done this - I’d say post here and ask - http://FastLED.io/r

(Unfortunately I’m doing a lot of project juggling and running around right now so this week is a terrible time for me to jump on a chat)

Have posted a post on there no replies yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.