Processing, raspberry pi and camera

[GoToLoop]

@neilcsmith

I tried to replicate the API in PraxisLIVE and gave up for another mechanism.

The standard way is to create a @FunctionalInterface so the library can call it back, like I did here:

Sequencer firing multiple events/ or one step behind

B/c there’s a slightly time loss during the time done is set to true and we check it ourselves, and only then we re-invoke start(), I don’t think class Countdown fits fully the requirements of your “sequencers”. Just made a variant of it called Interval, where done is set to true over & over at a fixed period time. We now need to call Interval::intervalDone() in order to check whether the previous interval had been completed. As a bonus, in place or in addition to check Interval::inte…

@GoToLoop

“Interval.java”:

  @FunctionalInterface public interface Callback {
    void run();
  }

“IntervalClass.pde”:

void createCallback() {
  interval.callback = new Interval.Callback() {
    @Override public void run() {
      fill(randomColor());
    }
  };
}

The interfaceless callback style is a much convenient way for Processing’s target coders though.

[neilcsmith]

@GoToLoop I understand the principle of functional interfaces, and use them a lot (seen as we fully support Java 8). However, that particular callback has issues. The only way to replicate it is to make things markedly less efficient. IMO (as maintainer of the underlying bindings to GStreamer incidentally) it is the wrong approach.

[GoToLoop]

@neilcsmith

However, that particular callback has issues.

You’re right! I’ve included the callback feature as an alternative bonus to the Interval class.

It is indeed mutating the sketch’s canvas in another Thread via fill()!

Also, due to the way Processing calculates the color, the result value becomes corrupted when used by more than 1 Thread for the same PGraphics!

But b/c it’s a random color, it doesn’t matter whether the color calculation got wrong!

[neilcsmith]

@GoToLoop I’m talking about the movieEvent callback. It should be removed from the video library, not added to the Pi one!

[GoToLoop]

As I remember, movieEvent() exists in the video library at least as far back as Processing 1.5.1; maybe it has always existed!

If such craziness you’re asking actually happens, a big portion of existing sketches & tutorials will need to convert the slick movieEvent() to this ugly available() inside draw()!

Not counting the other libraries should need to follow suit as well?!

[neilcsmith]

@GoToLoop this has nothing to do with anything else. I’m backing up gohai’s point that this particular callback is broken, not just for the reason he outlines, but because it also makes some other things very difficult or inefficient to implement. The video library is being updated to 2.x which should IMO be used to break it and make it better.

Anyway, enough going around in tangential circles! PM me if you want more info - pretty sure no-one else does.

[dan850]

Ok, I’m starting to sense some hostility in this thread. Obviously there are different approaches to handle any problem and some are more efficient than others. Lets try to be more respectful please.