Artsmesh project is going well: http://artsmesh.com
Graphic interface for P2P collaboration with jack/jacktrip, oscgroups, syphon/ffmpeg, chat, network tools, gnu social federated blog, router circle, video/audio mixer, live stream to Youtube, sync metronome/clocks with osc, score following, user/group profiles, world map of live streaming users, IPV6 enabled.

Pro-Presence Engineering Tool for Live Network Music Performance

Always willing to Skype with people to get them up and running.
Ken

2 Likes

hasn’t anyone invented the ansible yet?? i thought this was the future. :robot:

1 Like

I’ve been working through the Online Jamming class on Kadenze, the instructor is a bit difficult and the classes seem to be presented out of order, but there’s some good info there.

I’ve been able to connect with a friend about 70miles away and the latency seemed minimal, though the quality of connection was awful. Still troubleshooting, but could be promising.

1 Like

Really happy to see activity on this thread. Gonna try to find some time this weekend for testing.

Hmm. I’m on OS X 10.11.4

I’m getting curious about netpd:

2 Likes

Finally had my first NINJAM experience last night, thanks to @pirxthepilot, @mzero, @bellyfullofstars, and @ikjoyce.

Somehow, after a long week of work, I managed to hang in there for 4 hours straight (and I’m not generally a night owl at all). Wow. What an experience! Not only did it work, it worked way beyond my wildest expectations. All I can think now is “when do we do it again?!”

We had a bit of client-side trouble at first. Next time I’m going to try this plugin:
http://jamtaba-music-web-site.appspot.com

The setup that worked for most of us last night was to play through Reaper, which has native NINJAM support. That worked perfectly for NINJAM, but it introduced a new, and somewhat unfamiliar DAW, which wasn’t ideal. I think JamTaba might allow us to use our usual environments.

The diversity of instrumentation between the five of us was one of the best parts. Huge variety of analog, digital, and even acoustic instruments. I can’t think of any other network music approach that would allow for all that.

5 Likes

A jamming tip for the music theory impaired, from Ethan Hein’s latest blog post:

… the D minor pentatonic scale, and that scale turns out to fit fairly well over most current pop songs. If it doesn’t, some other minor pentatonic scale is very likely to work. This is due to a music-theoretical quirk of the pentatonic scale: it happens to share pitches with many other commonly-used scales and chords. As long as the root is somewhere within the key, the minor pentatonic will sound fine. For example, in C major:

C minor pentatonic sounds like C blues
D minor pentatonic sounds like Csus4
E minor pentatonic sounds like Cmaj7
F minor pentatonic sounds like C natural minor
G minor pentatonic sounds like C7sus4
A minor pentatonic is the same as C major pentatonic
B minor pentatonic sounds like C Lydian mode

Last night we seemed to settle on F minor. :wink:

1 Like

Dunno if this is the right place to ask… Here goes, anyway! Is there a standard way to ‘broadcast’ OSC messages? Here’s what I’m trying to do:

  • make the unused ‘f keys’ on my linux laptop somehow broadcast the fact that they’ve been pressed (probably by customising dwm, my window manager)
  • be able to create a puredata object with appropriate args… eg 'msg-subscribe <host> <port> /f1`
  • when I hit f1 key from any virtual desktop that puredata object emits a bang
  • my other application can ‘subscribe’ to the same key if it so chooses
  • I could reuse the methodology to, for example, broadcast a global clock signal to all ‘listening’ applications without knowing the port of their listening server (or even what machine they might be on)

I feel like UDP multicast doesn’t actually enable this, and I need to reach for some esoteric network library, e.g nanomsg.

On the other hand, I could just copy the ‘focus-snatching’ pattern from serialosc - not quite what I want, though. Seems to me there must be an easy way to do this, and that I’m ignorant of some really important standard technology!

OSC messages can use UDP or TCP transports. Discovery is via Zeroconf/Bonjour. On Linux that is handled by Avahi.

More clues:
http://opensoundcontrol.org/discovery-osc-clients-and-servers-local-network

So in practice as I understand it, the ‘standard’ way to achieve my goal is:

  • have dwm periodically poll avahi to refresh it’s list of all applications interested in my ‘f keys’
  • maintain a list of receiver ports inside my window manager ‘plugin’
  • explicitly send a UDP message to all of the subscribing ports

This just seems so terrible I was convinced it couldn’t be the case! I might have a very quick exploratory hack with nanomsg, pd & dwm just out of curiosity…

1 Like

maybe UDP broadcast address would help?

and if you can use nanomsg in every component there is builtin pubsub which i guess is built onUDP multicasting somehow? (i’m not very smart about this stuff)

1 Like

OSC is a pretty great protocol (very flexible and expressive, far more so than MIDI), but it does sound like the networking layer could use some work.

to be clear: there is no networking layer in the OSC spec. though it’s often referred to as a protocol it is really a data format, more analogous to JSON or protobufs than to, i dunno, TCP or CAN. it is just as likely to be used on a serial stream as anything else.

that said, the 1.1 spec from 2009/2012 does have some strong recommendations for delivery specifications (in a nutshell, use SLIP with double-END on streaming transports) and for integration with discovery services. e.g. an example DNS-SD/zeroconf listing:

_osc._tcp.localhost:5000 
    txtvers=1
    version=1.1 
    framing=slip 
    uri=http://myapp.com/ 
    types=ifsbhdu

i dunno, seems pretty complete for the goals of the project (which doesn’t include, for example, explicit mechanisms for clock sync, besides the timestamping itself…)

that was super easy - nanomsg is my new favourite thing! if anyone’s interested…


3 Likes

I tried Ninjam a few years ago:
Pro-Tip: Use Live with some virtual audio routing (jack) on a return channel to Reaper (running Ninjam).
That way you can preview stuff/jam/record/edit inside live before sharing via ninjam.
Worked like a charm. Thinking of it: I definitely have to do that again - once I got rif of the the chaos from moving houses …

1 Like

I’ve got a ninjam server set up and ready to go…

What is your preferred workflow for online jamming and performing in times of COVID-19 social distancing?

I started looking into ninjam wikipedia for online colabs and twitch for streaming, but I am not sure how to set up a performance stream of a collaboration… mainly because of bandwidth limitations.

Realtime online jamming is not very popular because it’s not a very good experience in the current state of technology. The name of the game here is latency.

Musical perception

As a rule of thumb, musicians playing live are able to ignore latency shorter than 5ms. This is easy to prove as most PA equipment in small venues will have latency around this mark.

However, latency above 10ms starts being frustrating, and once you get above 25ms you’ll be pretty much unable to play.

Video encoding

When you are recording video, the signal from your camera needs to be encoded. Like with audio, lossless encoding would take a ton of space so pretty much all consumer video formats are lossy.

If you’re recording to a file and you have a PC or a laptop, the encoder will likely put most priority on the quality of the file, not much priority in the size of the file. If you’re recording on a phone, the encoder will likely compress more to save on space, but even in this case size is not of paramount importance. This is because space efficient encoding requires a lot of CPU power, to the point where some devices might not be unable to record and encode in real time.

That’s part of the reason Netflix or Amazon Video look very good and enable you to stream HD even on relatively poor Internet connections while Skype and Zoom can look less stellar even on good connections on both ends of the call. Netflix is able to compress efficiently ahead of time while your Zoom call doesn’t have this luxury.

Also, video encoding adds some latency.

The Internet

The Internet as we know it was designed as a decentralized system able to withstand natural disasters, sabotage, and bombings of communication hubs. It’s pretty robust but that comes with some drawbacks, and unfortunately one of them is latency.

If you open a terminal on your computer and type “ping facebook.com” you’ll see how fast it takes for the simplest possible data packet to round-trip from you to the closest facebook.com server and back. If you’re really close to one of their datacenters, you might get something in the ballpark of 10-20ms. But typically you’ll see something closer to 50ms. And that’s pretty much the simplest case.

If you’re part of this industry you might object that there’s ways to cut this latency in half or more by using a specialized protocol. Yes, true, online gaming is proof that you can get pretty good results. However, games “cheat” by:

  • optimizing how much data is sent at any given point;
  • having a central server which is the point of reference and “the clock” for what is going on;
  • predicting players’ actions so that a lot of jitter is unnoticeable;
  • “fixing” small player errors that happen due to known latency.

Two-way video communication cannot use those optimizations easily.

Jittter, what’s that?

I mentioned jitter above which is the final nail to the coffin. Jitter is the variation of latency in time. You see, due to network congestion and network re-configuration, as well as hardware and software behavior, latency constantly changes. Imagine how hard it would be to play along if your click track constantly floats between 115 and 125 BPM. “On average” it might have been 120 BPM but you’d still be beyond frustrated trying to play along.

Specialized apps?

The current gold standard for regular VC calls is roundtrip latency of up to 300ms with jitter up to 30ms. That’s way beyond what’s acceptable for jamming.

You might have some success trying out various communication systems designed for gaming where latency is more important than in regular voice conference apps. However, even there you’ll find that the experience is probably bad enough that it’s hopeless. Especially now that so many people are sheltered-in-place so network and system congestion is high. Additionally, gaming systems usually sacrifice audio quality to achieve better performance. For us a relatively low-latency connection that sounds like AM radio would be a tough sell though.

Now that I gave you some technical background, you might be able to communicate the above to the people you want to jam with and try some specialized software like:

Your band needs to be relatively close geographically

Imagine there’s a fiber-optic wire between your computer and your band mate’s computer. If you are 1000 miles away from each other, the fastest roundtrip theoretically possible is 10ms: that’s because of the speed of light. But even a direct fiber-optic cable does not operate at 100% light speed. There will be many “hops”, which is network switching hardware, between you and your friend. In effect, you’re unlikely to see latency smaller than 30ms.

So, if you’re in the same city and the number of hops between you is relatively low, some of the gaming apps or the specialized apps might work. Good luck!

2 Likes

A friend keeps inviting me to Endlesss – I suppose I downloaded the app on Testflight (or what its called) since it has been open for Beta-testing. But I have so many machines calling for me that I haven’t found time to really dive into it.

They have some TV-channel on Twitch as well where you can see people jamming, I believe.

1 Like