The current core.async version causes issues with Clojure 1.9 . This is fixed at clojure/core.async@2f87bc7 . Consider upgrading to core.async-0.3.442 or the latest core.async to support Clojure 1.9.

Thanks.

Would you mind pushing 0.5.0-SNAPSHOT to clojars?

Hello, I'm playing around with Pink, and spotted something odd.

When you add new events to the engine, you always specify the start time relative to the current point of time.

This is ok when you add events from a control function (which is triggered accurately on every beat for example), but when you add events from outside of the engine thread, you may experience a significant clock skew.

In my case, I generate scores and add events from a separate thread (because sometimes it takes long time, and I would not like to put these heavy operations into the engine cycle).
So when I'm adding events, the EventList.cur-beat is almost random to me, so for each event, I have to manually de-reference it and compute the difference between the cur-time and the nearest beat boundary according to *tempo*, which is a bit inconvenient.

And, I spotted something in the Pink's code here:
https://github.com/kunstmusik/pink/blob/master/src/main/pink/event.clj#L111

The docstring says that the function adjusts event start times according to *tempo*.
But actually it doesn't use *tempo* at all, It adjust event times according to the cur-beat.

So, I thought that maybe this code was intended to work a bit differently?

@kunstmusik please let me know what you think

I've been trying to get Jack working with Pink. It seems to me that jnajack is the best solution.

After installing Java Native Access and jnajack
And adding jna.jar and org-jaudiolibs-jnajack.jar to my ext directory
I was able to run trough jack:
java -Xincgc -cp jna.jar:org-jaudiolibs-jnajack.jar org.jaudiolibs.jnajack.examples.SineAudioSource

It seems to me that engine.clj needs to be adjusted or alternative version created for JACK

Looking how SineAudioSource.java operaties with the jnajack library may give an idea how to send audio buffer to JACK (this may also be a bad solution, but after looking at clj-jack 0.0.1 which is based on overtone, I noticed that it's really the supercollider server that handles all communication to jack but not java).

package org.jaudiolibs.jnajack.examples;

import java.nio.FloatBuffer;
import java.util.EnumSet;
import org.jaudiolibs.jnajack.Jack;
import org.jaudiolibs.jnajack.JackPortFlags;
import org.jaudiolibs.jnajack.JackPortType;
import org.jaudiolibs.jnajack.util.SimpleAudioClient;

/**
 *
 * @author Neil C Smith
 */
@Deprecated
public class SineAudioSource implements SimpleAudioClient.Processor {

    private final static int TABLE_SIZE = 200;
    private int left_phase = 0;
    private int right_phase = 0;
    private float[] data;

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) throws Exception {
        SimpleAudioClient client = SimpleAudioClient.create("sine", new String[0],
                new String[]{"output-L", "output-R"}, true, true, new SineAudioSource());
        client.activate();
        while (true) {
            Thread.sleep(1000);
        }
    }

    public void setup(float samplerate, int buffersize) {
        data = new float[TABLE_SIZE];
        for (int i=0; i < TABLE_SIZE; i++) {
            data[i] = (float) (0.2 * Math.sin( ((double)i/(double)TABLE_SIZE) * Math.PI * 2.0 ));
        }
    }

    public void process(FloatBuffer[] inputs, FloatBuffer[] outputs) {
//        for (FloatBuffer buf : outputs) {
//            int size = buf.capacity();
//            for (int i=0; i < size; i++) {
//                buf.put(i, (float) Math.random() - 0.5f);
//            }
//        }
        FloatBuffer left = outputs[0];
        FloatBuffer right = outputs[1];
        int size = left.capacity();
        for (int i=0; i<size; i++) {
            left.put(i, data[left_phase]);
            right.put(i, data[right_phase]);
            left_phase += 2;
            right_phase += 3;
            if (left_phase >= TABLE_SIZE) {
                left_phase -= TABLE_SIZE;
            }
            if (right_phase >= TABLE_SIZE) {
                right_phase -= TABLE_SIZE;
            }
        }
    }

    public void shutdown() {
        System.out.println("Sine Audio Source shutdown");
    }
}

Attempting to find device names via :description is ineffective on Windows.

It appears the description field is rarely populated properly on Windows, for example on my system:

(map :description (list-midi-input-devices)) 
;=> ("No details available" "No details available" "No details available" ...)

This results in an exception being thrown whenever find-midi-device is called.

:name is however fully populated:

(map :name (list-midi-input-devices))
;=> ("lappy" "Audio Kontrol 1 In" ... "Real Time Sequencer")

Perhaps making find-midi-device search by :name once a :description based search has failed or doing different searches dependant on platform would be sensible solutions?

Imagine that you have a complex control function, or a function triggered by event.
It consists of many deeply nested function calls.
And in one of nested function calls, you need to manage control functions (or add new events).

Then you have a little problem: you need to remember the current engine, and pass it all the way down via function arguments, which is annoying.

Or, you can use a dynamic variable (e.g., *engine*), bind it at the top level, and then refer to it somewhere in the deeply nested function call.

That could be manually implemented by any Pink user as a bunch of wrappers around events/cfuncs (and actually I'm already doing this), but I think that it could be nice to have it out of the box.

So, I suggest to add the *engine* (or maybe *current-engine*) variable to config.clj
...and simply bind it in (engine-run), together with other dynamic variables.

@kunstmusik, the change is trivial, but I wonder if it somehow contradicts your design ideas?
I can implement it if you don't have time, just let me know....

Hi Steven, interesting to follow the development of Pink.

Anyhow, not an important issue but I get this error when starting the REPL:
error in process sentinel: Could not start nREPL server: Error occurred during initialization of VM
Too small initial heap for new size specified

And then I comment out
; "-Xms256m" "-Xmx1g"

Then the repl runs, but going trough the demos I hear a lot of distortion. Maybe unrelated?

In Clojure it is typical to store key-value pairs in maps. See entry in style guide.

Currently documentation for pink.io.midi recommends use of Strings:

Conventions are to use the following for virtual hardware
names:

• "keyboard x" - number of keyboard
• "knobs/sliders x" - number of knobs/slider device

What's the reasoning behind this?

Many functions name domain they operate on yet namespace all ready provides this information.

For example in pink.io.midi the following fn all refer to MIDI in there names. It'd be more inline with current practice to expect users to (:require [pink.io.midi :as midi]) and rename them as follows:

These functions could then be utilised through midi/list-devices etc.

find-midi-device appears to use .getMaxReceivers and .getMaxTransmitters incorrectly.

It appears you are using these methods in an attempt to confirm that a device is a valid input or output.

Unfortunately all you do is confirm that it does not have an infinite number of connections available in it by testing that there results >= 0.

The documentation for these methods state that they return the number of connections available or -1 if an infinite number are available.

As a result it's my belief that you should be checking the functions results are either > 0 or = -1 here. Using midi-input-device? and midi-output-device? would probably make a reasonably neat fix.