A few questions related to utilising track events/metadata

[pboled]

Hey @evanpurkhiser!

All your new Prolink typescript stuff looks really neat - kudos to you! It seems like you pulled it together incredibly quick since you first mentioned it in the Beatlink chat :)

I'm not a dev by trade but have was playing around with prolink-connect because I've always been keen on some kind of CDJ playlisting utility (that posts to an online endpoint/DB), and more familiar with JS/TS.

I've managed to get the basics working based on the sample code in the repo - e.g. network initialised and device events for connection/disconnection, but struggling to get the MixstatusProcessor + event emitter working.

Should something like the following vaguely work or am I overlooking something else critical?

const MixStatusConfig = {
      allowedInterruptBeats: 1,
      beatsUntilReported: 1,
      hasOnAirCapabilities: false,
      timeBetweenSets: 10
    }

    const mixstatus = new MixstatusProcessor(MixStatusConfig);
    network.statusEmitter.on('status', s => mixstatus.handleState(s));

    mixstatus.on(
      'nowPlaying',
      state => console.log("nowPlaying")
    );

    mixstatus.on(
      'stopped',
      state => console.log("stopped")
    );

Also, I'm using straight CDJ2000s (i.e. not nexus) and noticed that the electron app recognises the devices but doesn't seem to react to much else. Is it likely that these two things are related - i.e. the triggering of these events is critically linked to nexus-only elements?

Thanks for even taking the time to even read this far

[evanpurkhiser]

Hey @boledzp sorry for the late reply. Not sure why I don't get notifications in my email for these issues 😬

Are you using a DJM that's linked with the CDJs?

[pboled]

No stress at all, you've been more than generous enough making something in the first place.

Negative, no DJM with link in the mix just 2X CDJ2000. Is that a strict dependency? If not, is there any way to set config to have it work without?

[evanpurkhiser]

It's not a strict dependency no, but the MixstatusProcessor does make some assumptions about tracks being 'live' in order to report as playing.

We could probably add an option to the service that will ignore 'on air' indicators and just report tracks live if they've been playing long enough.

[pboled]

Ok, yep, if I understand correctly you're saying the MixstatusProcessor currently uses the on-air indicators as the 'live' triggers, which aren't emitted unless without a mixer as part of the setup.

Would it be possible to listen/query the CDJ track changes with the existing library myself? If yes, is there a particular class/method/technique you might suggest?

[pboled]

Little bump @evanpurkhiser, just in case you might have missed my reply

[evanpurkhiser]

Ah! Sorry for the very late response @boledzp :)

Yes you do understand correctly.

You very well can listen to the CDJ track changes with the existing library yourself. Something like this would work just fine:

const network = await bringOnline();
await network.autoconfigFromPeers();
network.connect();

let currentTrackId = null;

network.statusEmitter.on('status', status => {
  if (status.trackId !== currentTrackId) {
    console.log(`new track id! ${status.trackId}`);
    // Do things here
  }

  currentTrackId = status.trackId;
});

Though I am still at some point planning to make changes to the MixStatusProcessor to work when no on-air flag is available.