Howdy, Stranger!

We are about to switch to a new forum software. Until then we have removed the registration on this forum.

  • USB microphone and minim

    I've been struggling for ages to get a mini USB microphone setup. Starting to feel it might not be compatible...

    I need a robust solution that uses the USB mic every boot of the pi as it is headless and goes straight into running my sketch using minim to detect beats.

    Any reccomnedations of mics that work, the tiny cheap USB type, would be great. Also any advice of setup and ideally auto levelling the input would be great.

    I'm using this to beat match audio and the levels vary wildly from my flat to a club... The more plug and forget the better!

    Cheers :)

  • How can I do headless / virtual screen buffer pixel reading?

    Hi

    I currently have a setup with Processing running on Raspberry Pi, sending artnet messages across multiple universes to some Teensy's to do LED lighting animations using @cansik 's artnet library. I'm running into serious framerate issues - with drawing animations to screen, then reading from screen into a pixel buffer and then sending messages over artnet, it runs at approximately 7fps.

    I know that I can run the whole thing headless, or by not drawing to screen, my fps bumps up to 45-50fps, which is fine, but it limits my ability to make content through creating video or animations and filling my pixel buffer from there. Does anyone know of ways to do this maybe via a virtual screen buffer? The workflow would be create content and read pixels to a pixel buffer from screen during development, and then switch to a virtual buffer when running live.

    Code below. Setting the writeToScreen boolean to false, switches the code to writing directly to the pixel buffer.

    import ch.bildspur.artnet.*;
    import processing.serial.*;
    
    //___________________________
    // setup pattern
    boolean readFromScreen = false;
    boolean writeToScreen = true;
    Pattern patterns[] = {
      new TraceDown(), new TraceDown(), new TraceDown(), new TraceDown(), new FadeTrace(), new TraceDown(), 
      new TraceDown(), new TraceDown(), new TraceDown(), new TraceDown(), new FadeTrace(), new TraceDown(), 
      new TraceDown(), new TraceDown(), new TraceDown()
    };
    
    //___________________________
    // setup artnet 
    ArtNetClient artnet;
    int numUniverse = 15;
    int numChannels = 510;
    byte[] dmxData = new byte[numChannels];
    ArtnetDMX Artnetclass = new ArtnetDMX();
    
    //___________________________
    // stetup serial
    Serial port;  // Create object from Serial class
    String data = "0 0";     // Data received from the serial port
    int[] nums;
    byte[] inBuffer = new byte[4];
    
    int windSpeed;
    int windDir;
    float windSpeedCal;
    
    //___________________________ 
    // setup leds
    int numLeds = 88;
    color led[][] = new color[numChannels/3][numUniverse];
    int size = 2;
    color[][] pixelBuffer = new color[numChannels/3][numUniverse];
    
    //___________________________
    // setup timer
    long[] ellapseTimeMs = new long[numUniverse];
    long[] ellapseTimeMsStartTime = new long[numUniverse];
    float durationMs = 3000;
    boolean direction = true; 
    
    
    //_________________________________________________________
    void setup()
    {
    
      size(300, 80);
      colorMode(HSB, 360, 100, 100);
      textAlign(CENTER, CENTER);
      textSize(20);
    
      // create artnet client without buffer (no receving needed)
      artnet = new ArtNetClient(null);
      artnet.start();
    
      // create port
      //String portName = Serial.list()[0];
      //port = new Serial(this, portName, 2000000);
    }
    
    //_________________________________________________________
    void draw()
    {
      // create color
      int c = color(frameCount % 360, 80, 100);
    
      background(0);
      stroke(0);
    
      //change direction
      if (ellapseTimeMs[0]> durationMs) direction = !direction;
      // choose pattern to run on LED strip
      // int pattern = 0;  
      for (int i = 0; i <numChannels/3; i++) {
        for (int j = 0; j < numUniverse; j++) {
          if (ellapseTimeMs[j]> durationMs) {
            ellapseTimeMsStartTime[j] = 0;
          } else if (direction==true) {
            float position = i/(float)(numChannels/3);
            float remaining = 1.0 - ellapseTimeMs[j]/durationMs;
            if (readFromScreen == false){
              pixelBuffer[i][j] = patterns[j].paintLed(position, remaining, led[i][j]);
            } else {
              led[i][j] = patterns[j].paintLed(position, remaining, led[i][j]);
            }
    
          } else {
            float position = 1.0 - (i/(float)(numChannels/3));
            float remaining = ellapseTimeMs[j]/durationMs;
            if (readFromScreen == false){
              pixelBuffer[i][j] = patterns[j].paintLed(position, remaining, led[i][j]);
            } else {
              led[i][j] = patterns[j].paintLed(position, remaining, led[i][j]);
            }
          }
        }
      }
    
      if (writeToScreen == true) {
        showPattern();
      }
    
      if (readFromScreen == true){
        updatePixelBuffer();
      } 
    
      Artnetclass.updateArtnet(artnet, dmxData, pixelBuffer);
      //oldUpdateArtnet();
    
      updateEllapseTime();
      println(frameRate);
    
      // show values
      //text("R: " + (int)red(c) + " Green: " + (int)green(c) + " Blue: " + (int)blue(c), width-200, height-50);
    }
    
    
    // clock function
    void updateEllapseTime() {
      for (int j = 0; j < numUniverse; j++) {
        if (ellapseTimeMsStartTime[j] == 0) {
          ellapseTimeMsStartTime[j] = millis();
          ellapseTimeMs[j] = 0;
        } else {
          ellapseTimeMs[j] = millis() - ellapseTimeMsStartTime[j];
        }
      }
    }
    
    // storing pixels from screen
    void updatePixelBuffer() {
      for (int i = 0; i < numChannels/3; i++) {
        for (int j = 0; j < numUniverse; j++) {
          // read screen pixels and assign to pixel buffer
          //pixelBuffer[i][j] = get(i*size/2+(size/4), j*size+size/2);
          pixelBuffer[i][j] = get(i*size +size/2, j*size+size/2);
          fill(pixelBuffer[i][j]);
          stroke(pixelBuffer[i][j]);
          rect(50+i, 50+j, 1, 1);
        }
      }
    }
    
    // draw pattern on screen
    void showPattern() {
      for (int i = 0; i < numChannels/3; i++) {
        for (int j = 0; j < numUniverse; j++) {
          // show only pixel buffer if not reading from screen
          if (readFromScreen == false){
              fill(pixelBuffer[i][j]);
            } else {
              fill(led[i][j]);
            }
          rect(i*size+size, j*size+size, size, size);
        }
      }
    }
    
  • Trying to get P2D/P3D working on ARM dev Board [Mali-400]

    @gohai, No, it did not make any difference. Infact i tried many other suggestions found online, nothing worked.

    Considering Mali-400 was released in 2008, more than 10 years have passed...even so, i see developers are still confused about how to approach/solve this "Mali issue".

    I am completely fine using binary blobs instead of an open-source solution. i currently use all my ARM boards in a headless environment. and probably will use a low-power x86 board like brix/UpSquared for the Processing based project.

    I even ran Processing on 586 class 433Mhz AMD Geodes / Vortex DX2 and a VGA Monitor, on a 16mb Linux based OS.

    People blame chinese SoC vendors for gpu driver problems, but i think the only one responsible is ARM and Google. really frustrating :(

  • Trying to get P2D/P3D working on ARM dev Board [Mali-400]

    @solidsnake: Perhaps you need to disable "glx" as done in the first post here. I don't have hardware to test, unfortunately .

    SOC getting hot: don't think we can do anything about this.

    ARM64 version: we had one, but then realized that Oracle's JDK for arm64 seem to all be of the "headless" kind, meaning that they are not suitable for running Processing. You can run it with OpenJDK, and it will work, but so far I haven't found time to test and put together a release with it.

  • Is there currently any workaround for running processing on AWS Cloud9?

    Due to some special circumstances, I have been forced to migrate most of my development over to a cloud environment, which also means primarily working on web development. I have enjoyed working with P5js but there are some key differences, particularly with 3d rendering.

    I only recently occurred to me that AWS Cloud9 does support Java and that I might be able to just use processing after all. However, after installing the tgz and running the Program it threw an error because the server is headless as it is hosted on a cloud.

    Just hoping someone else has maybe attempted this and can share some insights.

    Is there a workaround? should I just give up? Is it theoretically possible?

    Tried searching around on the forum as well as some googling to no avail.

  • [Proposal] - Development Environment: JavaScript Prototype

    Thanks for this very thoughtful proposal. A couple quick notes, then the two big pieces are on the Design and Scope section. The quick things first:

    • Base Framework: Agree that Electron is the way to go

    • Code Editor: p5.js using CodeMirror (and your experience with that) sounds like the right thing

    • UI/Frontend: React seems to be the thing

    • Testing: sure, with an eye toward maintaining parity with the current PDE. Though it's also a lower priority than getting something working and may be out of scope for a summer-length project.

    • L10N, I18N, A11Y: are all important, yes. You'll want to build on the work that's already been done for the PDE, as significant effort has gone into localizing the various messages in the PDE itself.

    • App Distribution: we could do the app stores now, but do not, mostly because they require additional work and restrict features. They're also somewhat incompatible with the "sketchbook" model we have in place. Basically it'd be extra effort to support a more-closed system, and I'd still have to produce non-app store versions. Auto-updating would be nice too, but these are all laundry list features that would be outside what can happen in a GSoC project (relative to the other priorities).

    • Language: sounds good… I go back and forth on TypeScript, and can be convinced either way.

    • Package Manager: aren't you more-or-less stuck w/ NPM if you're using Electron anyway?

    • Tooling: sure

    And the longer points:

    Design

    We'll want to stick with the current 3.x design. The p5.js editor is a different project, and has a different audience and use case. We're looking for a direct port of the current state of the PDE that we can build on later. It's a mature application that's received a lot of work, has a lot of users, and a lot of resources and materials that describe the location and use of various features. Switching to the p5.js editor layout would be a step backwards: it's very early in its development and would remove too many things.

    A general-purpose editor is also not a design goal—that's a distraction to getting something that works well for our use case. There are tons of editors out there, we don't need another generic one. And if anything, I think the p5.js editor and PDE should probably be diverging from one another—to be more specific to their use cases—rather than converging. (That last point is not a Foundation statement, it's me thinking out loud.)

    Scope

    The current CLI is very limited. It's really just the minimum to allow folks to run the app headless from their favorite editor. Wiring the CLI to a simple text editor that looks a bit like the current PDE as an electron app would be the first week or two of the project.

    The CLI isn't really the way to go for anything further than that. Put another way, if this is just a frontend on the CLI, then why do it at all? We should just be sending people to more complete editor platforms and IDEs. The point of the PDE is how it ties the project together: making it easy for people to get started, to install and use libraries, to not have to think about the CLASSPATH, Java version, etc.

    The real meat of making this project work is two things: first is feature parity/alignment with the PDE, and the second is how to make the debug/autocomplete/etc code work with the frontend.

    The feature parity issue is that while the PDE seems like a "simple" editor, there's a great deal of things that it can do, and that users expect it to do. A lot of the complexity is hidden from users, but rebuilding it is an enormous task. I don't expect we'd have 100% parity with the PDE in a single GSoC project. (But of course I'd love to be wrong!)

    For debug/autocomplete/etc, that's much trickier. You'd be working with Jakub and me to sort out how to best wire all that to a JS frontend, because it's both complicated and also needs some housecleaning along the way.

    Again, thanks for the proposal. Hopefully we'll have a chance to work with you on the project this summer.

  • [Proposal] - Development Environment: JavaScript Prototype

    Development Environment: JavaScript Prototype

    Dhruvdutt Jadhav
    GitHub: dhruvdutt | Website: dhruvdutt.github.io | Email: dhruvdutt.jadhav@gmail.com


    Introduction / Abstract

    The Processing Development Environment (PDE) has more than 250k unique users and is currently built in Java using custom components that make use of Java's “Swing” library. This proposal aims a prototype replacement for the PDE itself with a JavaScript-based solution.


    Background

    The Processing IDE has 2 major components: - Code Editor: 'frontend' - Compiler/runner: 'backend' that converts processing code to pure Java code, compiles and runs the program.

    The current PDE user interface is built in Swing and the code editor is a standard text view. When we click "run", the PDE converts Processing code to pure Java source code and then there's a 'runner' component that does the job of actually running the Java program. Everything except this part will need to be basically written from scratch.


    Project Description

    The prototype we're planning would be a native desktop app built using web technologies like JavaScript. It would have a Processing code editor and will allow the user to compile and run the code through the Java compiler or runner.


    Approach

    For the prototype, we can imagine a basic version of VSCode or Atom like editor which lets you code in Processing language.

    We will use a cross-platform framework, integrate a code-editor and rewrite the web components. More details are given below in technical specifications.

    For the parsing the code, we'll need to pass it through the runner/compiler which resides inside the monolith PDE repo. Processing does have a CLI (command line tool) that basically takes a sketch folder and runs it in a "headless" version of Processing (without launching the full PDE). We can leverage or tweak that to our use for the prototype.

    The UI editor and components can stay JavaScript based and will communicate with the Processing CLI to run/pause/stop the sketch. We can use Node.js Child Process to accomplish this and use the stdout from CLI through the child process (inside Electron) and then pop it.

    An alternative to using CLI is to actually translate the sketch code to pure Java, compile and run it as a standard Java program. Processing's core libraries are standard java libraries, so it's possible to run it as a pure Java program too. But it will be significantly more work than using the CLI directly. We would need to use something like node-java to connect with existing Java APIs and form a bridge but it might take a while in itself to figure out and stitch all the internal libraries together before doing any communication.

    I think right now, we can focus on the exposing more and more features via CLI as per the requirements of the prototype. This way, we can keep developing the current PDE and the improving CLI together, and at a future stage when things are stable enough we can entirely ditch the Swing components.

    We can keep the CLI as a bridge to only do the essential compilation and parsing of the Processing code and implement the rest of the features within the new prototype gradually.

    Apart from this, the PDE also supports error reporting, code completion (intellisense), refactoring features too. These features currently use other 3rd party Java libraries. So porting these features over might be a bit tricky initially. These could be implemented using libraries like Tern.js but we can keep this at the back of our minds and cover this once we get the initial prototype ready.

    Building the complete PDE would definitely take lots of effort. I'm seeing this proposal as building a strong bedrock foundation on which we can scale and iterate incrementally.

    One of the goals to build this new prototype is moving away from Java's Swing components code and embrace JavaScript for frontend and UI components. JavaScript is best known for it's terse declarative, flexible and dynamic behaviour which makes it easy to pick and faster to iterate. It will also attract a more active open-source community and will lower the bar of entry for contributions.


    Technical Specifications:

    Base Framework

    A base framework that allows building native desktop applications using web technologies like JavaScript, HTML, CSS.

    We'll use Electron as our base framework as it's one of the most popular projects used for building native applications and is backed by GitHub. Tools like VSCode, Atom are built on Electron which has similar use case as us.

    Code Editor

    For taking Processing code as input from user, we'll need a code editor that runs on web technologies (or an in-browser code editor).

    There are again a bunch of choices here but I've picked CodeMirror which is one of the oldest and most actively maintained code editors. It has support for tons of languages out-of-the-box, has an active community forum and has way more users and downloads (npm downloads) even after combining all of its alternatives. Live use cases similar to us are Adobe Brackets and Chrome DevTools (in case we plan to build some console utilities at a later stage). Also, our very own Processing family's p5.js web editor uses CodeMirror as well.

    CodeMirror has out-of-the-box support for Java which we can start off with and it also features something called "mode system" that allowing supporting custom language syntax highlighting and markup which we can use for our Processing code inside the editor. There's also a 3rd party library called CodeMirror Grammar which transforms a JSON grammar object into a syntax-highlight parser for CodeMirror. We can also look into it.

    In terms of code editors, there are alternatives like Monaco which is built by the VSCode team at Microsoft. It's the go-to editor if the target users would be working primarily for JavaScript inside the editor. Monaco doesn't support many languages out-of-the-box but they have very good docs about writing custom syntax and languages.

    UI Components

    "The current custom components make use of Java's “Swing” library, which is even more outdated now than when it was first released".

    We'll need to rewrite the UI components from scratch which should be fairly straightforward and can be concretely planned. We'll try to use native things as much as we can, like the menu bar which would be native and look platform specific (similar to how VSCode, Atom does). The alternative is we build a custom menu bar with custom styles that would be inline and sticky in the header at the top of the IDE. (similar to Google Docs/Sheets menu bar)

    Frontend Library

    We'll also need a frontend library to connect and render all the UI interfaces and for managing application state. I've chosen React.js as it provides a simple yet flexible API for building user interfaces, follows components based architecture pattern, wildly popular, actively developed, backed by Facebook and has one of the biggest JavaScript communities. Redux: For application state management, Reselect for memoizing selectors if needed. React and Redux is also used in the p5.js web editor.

    Design

    We can take inspiration from the p5.js web editor design looks minimalistic and beginner-friendly. We can port these styles directly to keep things consistent and tweak a few things like Processing's dark blue colour theme and logo. Also, it is recommended to create a standalone design kit components library in future that would contain common components styled along with a way to inherit/extends them. This can be consumed by both p5.js web editor and the new PDE or any future web-based project and can serve as a design spec for all Processing web projects.

    Testing

    Testing is the roof of any app. As the app grows, testing will help us scale and iterate faster. Lacks of tests has been one of the issues with the current PDE. It's hard to maintain them with limited resources. For the new prototype, most of the internal methods and APIs will keep on changing/refactoring. It doesn't make sense to follow TDD from Day 0. We would try to write modular code in a way which facilitates easy testing at a later stage once the internal APIs and methods are in a stable state.

    Unit testing would be good to start off with. There are testing frameworks specialized for each type of tests but Jest works for most cases. It is backed by Facebook and is wildly popular in React - JavaScript ecosystem. This is something which can be revisited at a later point in time.

    Localization, Internationalization and Accessibility

    Since the PDE would be targetting a wide audience, l10n, i18n and a11y can't be neglected and are one of the most crucial things to support. This is also something in backlog at the moment till we decide the priority of these in context of the current prototype.

    App Distribution

    Currently, the PDE is only distributed via the downloads page and GitHub releases page. The PDE prompts you with an update message if a new version is available.

    With the help of Electron, we can distribute it to Mac App Store, Windows Store and also do the update automatically in the background (similar to how VSCode, Atom updates itself). There would be platform specific executables/msi/zips/tgz for sure along with this.

    Although app distribution as a whole can be addressed at a much later stage in the project, we should keep in mind the possibilities which could be unlocked.

    Language

    For the programming language, we'll be using JavaScript/ECMAScript ES6/7 with Babel (transpiler/JS compiler) which will allow us to write modular code using latest syntax, semantics.

    I'm also open to and have experience using statically typed languages like TypeScript which might help to get Java developers onboard but IMO we should stick with JavaScript.

    Package Manager

    For managing and installing all the packages and dependencies inside our project, we'll use npm which comes bundled with Node.js We can also use Yarn alongside npm.

    Tooling

    We'll also using some additional tools along with all above libraries:


    Summary

    • The whole technical stack comprises of most popular and battled-tested tools having similar live use-cases as ours. Personally, I'm acquainted and have worked with all of the technologies listed.

    • The technologies are very similar to the current p5.js web editor. This will help improve developers and contributors experience switching between projects.

    • We can expect to see a good number of outside JavaScript contributions from one of the biggest open-source communities.

    • The major objectives we've covered/unlocked are:

      • Allow more people to contribute to PDE's further development.
      • Provide better support for building the UI by using JavaScript.
      • Have more visually consistent cross-platform results.
      • Potentially open up other ways to distribute the PDE.

    Scope

    For the initial prototype, we can imagine a basic version of the current PDE with a code editor and an option to run the sketch. The technical plan proposed forms a good foundation for a future scalable product. Most of the UI components would be covered in the prototype itself and once we form the communication bridge with the CLI properly, we can incrementally port and migrate the rest of the features.

    Development Process (Timeline)

    The timeline will be planned once this initial proposal is approved and we finalize the things to cover in the initial prototype.

    Discussion

    • What is the current state of the Processing CLI in terms of stability and how regularly is it maintained?

    • Are there any features that currently aren't supported/exposed by the CLI which we want to accomplish in the prototype version? Currently, the --help command shows these supported options.

    • Finalize the scope and things to cover in the prototype.


    About me whoami

    I'm Dhruvdutt Jadhav, a software engineer and a student from DAIICT, India. I'm currently in my final year of masters and have also completed React Nanodegree from Udacity.

    I'm one of the co-authors and maintainers of ReactiveSearch - a React based web and native UI components library for Elasticsearch. I'm also one of the members and collaborators of webpack team and have done noteworthy contributions to webpack-cli. I've also done other minor contributions to yarn, yarn-website, create-react-native-app, react-router and many other open-source libraries. You can catch all my contributions on GitHub.

    I've also contributed to Processing's p5.js-web-editor in submitting some patches and upgrading major packages.

    Apart from this, I've built many web-based production apps and have primarily worked with JavaScript and React in my most closed source projects. You can learn more about them in my resume.

    I'm very proficient working with JavaScript and web technologies in general. I've also worked with Java at an intermediate level and have built an open-source library to manage multiple filesystems as a part of my college project. Know more about it here.

    I learnt about Processing a while ago and would love to be a part of its family for GSoC and beyond.

    My details:

    • GitHub: dhruvdutt
    • Website: dhruvdutt.js.org
    • Email: dhruvdutt.jadhav@gmail.com
    • Timezone: UTC +5.30 (India). I'm a nocturnal person but open to work under any timezone.

    Note: Big shout-out to Manindra Moharana for helping me throughout with the approach.

    Thank you very much everyone for taking out time to read my proposal. I really appreciate your feedback and guidance about it.

  • Exported program fails silently

    I exported the Adafruit's Adalight program to have LEDs behind the TV with my Arduino

    Zero experience with the Adalight... can you comment what it is and what is its role in your setup? Is it a stand alone system similar to a raspberry-pi? What is the display of that device? Or are you running the Processing sketch in headless mode?

    Kf

  • Exploring PApplet and PGraphics, trying to create headless graphics

    This is 1 of 2 posts. In this one I will describe my attempt to create a standalone PGraphics to a file without a PApplet. I am interested in simplifying code to generate files, and in interoperating with Swing. I am willing to add classes to the hierarchy to do this without interfering with anyone's existing code or how it works.

    The problem is that PApplet and PGraphics are extremely convoluted, so any help in trying to unravel would be appreciated.

    First of all, I tried to create a PGraphics writing an image without opening a PApplet.

    PGraphics g = new PGraphics();
    g.setPrimary(false);
    g.setSize(320,200);
    g.beginDraw(); // seems unnecessary
    g.background(0xFF0000);
    g.stroke(0xFFFFFF);
    g.line(0,0, 300,300);
    g.rect(100, 200, 100, 50);
    g.endDraw();
    String path = System.getProperty("user.dir");
    g.save(path + "/test.jpg");
    

    This generates a jpg but it is black, nothing draws. debug shows:

    pushMatrix is not available in this renderer resetMatrix() popMatrix() blendMode()

    How is the renderer set? I would like to attach this. Note that this is not headless graphics, but I can then at least create a simple class that does this cleanly and does not open a window.

    If I can get the above example working, the next step would be:

    PGraphicsJPEG g = new PGraphicsJPEG(320, 200);
    g.stroke(...);
    g.line(...);
    g.save("test.jpg");
    

    However, if generating PDF files, it seems to me I should be able to create something completely headless. OpenGL may require me to connect to a device, but pdf surely does not. I was hoping that perhaps P2D might not, but I suspect that P2D uses OpenGL and therefore is similarly tied to a working graphics display.

  • How can we make Processing on ARM & Raspberry Pi better?

    It would be really helpful to (optionally) specify the sketchbook/library directory using the command-line tool, or better still - allow contributed libraries to be installed at the same time as the main program or through a separate cli.

    I have a Processing 3 sketch running on Debian Stretch on a headless RPi3 and it works perfectly if no contributes libs are imported (thanks to this!).

    But when using the command-line to run the sketch that does import a contributed library I get this:

    root@bdd360b:/app# processing-java --sketch=./display_sketch --present Sketchbook folder disappeared: The sketchbook folder no longer exists. Processing will switch to the default sketchbook location, and create a new sketchbook folder if necessary. Processing will then stop talking about itself in the third person. No library found for processing.video Libraries must be installed in a folder named 'libraries' inside the sketchbook folder (see the Preferences window). display_sketch.pde:0:0:0:0: The package “processing.video” does not exist. You might be missing a library.

    The library is cloned into ~/sketchbook/libraries (I found the folder first, then specified it in preferences.txt like this: sketchbook.path.three=~/sketchbook) and it's also cloned into the folder containing the sketch directory.

  • 3.3.7 on ARM & Raspberry Pi: What's New

    @gohai the key thing was you said current Oracle 64-bit was headless?! I haven't tried Zulu Embedded yet, though plan to in the next few weeks. It's meant to be feature and performance comparable, and with GUI support. I use Zulu with Processing / Praxis LIVE on Windows and MacOS though, and hand it out at workshops if people don't have a JDK. It's a good drop-in replacement. Matching specific versions should be doable - think the version numbers line up these days.

    The warning is going to have to go soon anyway, seen as Oracle will be shipping OpenJDK (as I mentioned) as their free Java option - https://blogs.oracle.com/java-platform-group/faster-and-easier-use-and-redistribution-of-java-se

  • 3.3.7 on ARM & Raspberry Pi: What's New

    @SiriusCG The one issue with 64-bit ARM was that it turned out that Oracle's JVM releases for that platform were of the "headless" kind, so they don't include the necessary bits for graphical applications. Unsure why this is this way really...

    It seems that we would have to switch to using OpenJDK for 64-bit ARM, which needs some tooling work and convincing that it's worth the extra complexity. Especially since there isn't yet a Raspbian release that would make use of all this. But it's on the list!

  • Using p5.js with node, nwjs, express?

    I believe the p5 NPM module is just for running headless tests. :(|)

  • UnsatisfiedLinkError in Eclipse

    @kfrajer I actually learned all about headless mode. Originally, I was trying to run this program that way, but it gave me fits, and ultimately led to my conclusion in the previous post. That is an interesting thought, however. Are you suggesting that if I can get it running on a raspbian lite OS, and run the application on there, that it wouldn't have to do the graphical processing?

    As far as your first suggestion, that is another great idea. I will see if that helps. If not I'll just take processing out of the equation, which seems doable as well.

  • UnsatisfiedLinkError in Eclipse

    I think what matters for this calculation is the buffer size and not so much the sampling rate. I will guess the buffer size of your app could be 1024 bins. Maybe you could lower it to 256 and see if this helps. I would suggest using the default sketch size of 100x100 is the lowest you can go but should reduce overhead. Unfortunately, these changes might not make any major improvement and you are truly limited by your platform.

    @jeremydouglass Do you know anything about running processing in headless mode? I believe I saw a post talking about his mode, running processing in a server where there was no graphical support. I might be using the wrong terminology.... or I might be wrong and I could have seen it in another forum.

    *****EDIT: More about headless mode:
    https://forum.processing.org/two/search?Search=xvfb
    https://forum.processing.org/two/search?Search=headless

    Kf

  • Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException

    Your example gives an ExceptionInInitializerError

    Consider the following code, which I modified from java.awt.GraphicsEnvironment:

    class Testor {
    
        private static Boolean headless;
        private static Boolean defaultHeadless;
    
        private static boolean getHeadlessProperty() {
            System.out.println("Upon entry, headless is: " + headless);
            if (headless == null) {
                    String nm = System.getProperty("java.awt.headless");
                    System.out.println("java.awt.headless is: " + nm);
                    if (nm == null) {
                        /* No need to ask for DISPLAY when run in a browser */
                        if (System.getProperty("javaplugin.version") != null) {
                            headless = defaultHeadless = Boolean.FALSE;
                        } else {
                            String osName = System.getProperty("os.name");
                            System.out.println("osName is: |" + osName + "|");
                            if (osName.contains("OS X") && "sun.awt.HToolkit".equals(
                                    System.getProperty("awt.toolkit")))
                            {
                                headless = defaultHeadless = Boolean.TRUE;
                            } else {
                                final String display = System.getenv("DISPLAY");
                                System.out.println("display is: " + display);
                                System.out.println("defaultHeadless is: " + defaultHeadless);
                                headless = defaultHeadless =
                                    ("Linux".equals(osName) ||
                                     "SunOS".equals(osName) ||
                                     "FreeBSD".equals(osName) ||
                                     "NetBSD".equals(osName) ||
                                     "OpenBSD".equals(osName) ||
                                     "AIX".equals(osName)) &&
                                     (display == null || display.trim().isEmpty());
                            }
                        }
                    } else {
                        headless = Boolean.valueOf(nm);
                    }
            }
            System.out.println("About to return result: " + headless);
            return headless;
        }
    
      public static void main(String [] args) {
        System.out.println(getHeadlessProperty());
      }
    
    }
    

    Here is what happens when I run it from OpenJDK and from the java that comes with Processing. A result of false means that there is a graphic display; a result of true means there is no graphic display.

    david@raspberrypi:~/testor> java -version
    openjdk version "1.8.0_121"
    OpenJDK Runtime Environment (IcedTea 3.3.0) (suse-3.7-aarch64)
    OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)
    david@raspberrypi:~/testor> java Testor
    Upon entry, headless is: null
    java.awt.headless is: null
    osName is: |Linux|
    display is: :0.0
    defaultHeadless is: null
    About to return result: false
    false
    
    david@raspberrypi:~/testor> ~/processing-3.3.3/java/bin/java -version
    java version "1.8.0_131"
    Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
    Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
    david@raspberrypi:~/testor> ~/processing-3.3.3/java/bin/java Testor
    Upon entry, headless is: null
    java.awt.headless is: true
    About to return result: true
    true
    
  • Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException

    After looking at the source and doing some testing, the problem is that the version of Java that I am using (downloaded from jdk-8u131-linux-arm64-vfp-hflt.tar.gz) has java.awt.headless set to true Setting the flag to false on the command line doesn’t help; you then get an error that libawt_xawt.so can’t be loaded. [Later edit:] It would appear that graphics aren’t a part of that particular distribution at all.

  • Having a hard time getting processing to run after install

    The program 'java' can be found in the following packages: * default-jre * gcj-4.8-jre-headless * openjdk-7-jre-headless * gcj-4.6-jre-headless * openjdk-6-jre-headless Try: sudo apt-get install

  • Rendering using P2D on an EC2 instance?

    I am using a recursive trig function to make super high definition symmetrical spiral shapes that morph into one another, but because of the computation involved, it is very slow: ~6 hours for a minute of footage (1440 frames) on my mbp.

    The P2D renderer doesn't make it go that much faster on my computer, but I thought there might be a way to make use of a GPU instance on EC2 via OpenGL?

    Thanks to one of Daniel Shiffman's tutorials, I managed to get a sketch running on EC2 and exporting .png files using the default renderer - would I just be better off getting a compute instance and using the default renderer? I was curious so I hired a larger compute instance, but it rendered the frames only very slightly faster than the free tier instance.

    Any advice / pointers / resources wrt rendering headless on EC2 would be amazing!!