Praxis vs supercollider vs pd

92 views
Skip to first unread message

brandon taylor

unread,
Jun 16, 2017, 3:41:18 PM6/16/17
to Praxis LIVE software discussion group
How does praxis live honestly stack up against puredata and super collider. I mean I'm trying to learn and use programming languages or live coders extensively for music?

Neil C Smith

unread,
Jun 16, 2017, 4:07:56 PM6/16/17
to praxi...@googlegroups.com
Hi,

On Fri, Jun 16, 2017 at 8:41 PM brandon taylor <btaylo...@gmail.com> wrote:
How does praxis live honestly stack up against puredata and super collider. I mean I'm trying to learn and use programming languages or live coders extensively for music?

Pure Data and SuperCollider are rather different.  It really depends what you want to do.  Praxis LIVE has less features out of the box than those two environments, but it's also more flexible and allows you to go as low level as you want to go.  Replicating the AMEN $ Mother Function performance in the video you commented on would be more difficult in those environments because I'm literally running code against every sample rather than building something up out of pre-built units.  On the other hand, almost all other live coders aren't doing this!  If you're interested in getting into live-coding things like musical patterns, though, I'd recommend checking out TidalCycles https://tidalcycles.org/ - it's a system focused on that one thing and does it exceedingly well.  It uses SuperCollider as its sound engine.

I've not used SuperCollider directly so can't comment on its usability, but I would hope the patching side of Praxis LIVE is easier to get on with than Pure Data.  At least, the Pd interface annoys the hell out of me every time I try and use it! ;-)

Best wishes,

Neil
--
Neil C Smith
Artist & Technologist

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Jean-François Hicter

unread,
Feb 28, 2020, 6:40:15 AM2/28/20
to PraxisLIVE software discussion group

Pure Data and SuperCollider are rather different.  It really depends what you want to do.  Praxis LIVE has less features out of the box than those two environments, but it's also more flexible and allows you to go as low level as you want to go.  Replicating the AMEN $ Mother Function performance in the video you commented on would be more difficult in those environments because I'm literally running code against every sample rather than building something up out of pre-built units.  On the other hand, almost all other live coders aren't doing this!  If you're interested in getting into live-coding things like musical patterns, though, I'd recommend checking out TidalCycles https://tidalcycles.org/ - it's a system focused on that one thing and does it exceedingly well.  It uses SuperCollider as its sound engine.

TidalCycles is great for sequencing, but, it is very limited if you want to achieve synthesis with it: all the live-coders I saw are using SuperCollider sampler resources...   Never saw a coder dealing with TidalCycles and SuperCollider synthesis resources... I mean using the SC interface and the TC interface at the same time...

This said, I never dived into SC and TC on Linux (my current system) for technical reasons...

I've not used SuperCollider directly so can't comment on its usability, but I would hope the patching side of Praxis LIVE is easier to get on with than Pure Data.  At least, the Pd interface annoys the hell out of me every time I try and use it! ;-)

Sure! Lol! If you have a bad memory like me, this is not possible to deal with those little annoying boxes and their esoteric code!
So, the question is: Is PraxisLIVE the combination between TidalCycles and SuperCollider?
Ahah!


Neil C Smith

unread,
Feb 28, 2020, 6:56:47 AM2/28/20
to Praxis LIVE software discussion group
On Fri, 28 Feb 2020 at 11:40, Jean-François Hicter <hic...@gmail.com> wrote:
> Sure! Lol! If you have a bad memory like me, this is not possible to deal with those little annoying boxes and their esoteric code!

Welcome! Yes, there's a level at which node environments work, and a
level where they don't!

> So, the question is: Is PraxisLIVE the combination between TidalCycles and SuperCollider?
> Ahah!

No. At least certainly not out of the box it doesn't have, or aim to
have, that amount of functionality. On the other hand, there is one
thing you can do in PraxisLIVE that you cannot (easily) do in
SuperCollider, and that is actually live re-code down at the sample
level (ie. as if recoding the ugens themselves).

The closest environment to PraxisCORE (the runtime bit of PraxisLIVE)
in the live-coding area is probably Extempore. PraxisCORE likewise is
intended to be a cyber-physical runtime - ie. for real-time
programming of real-time systems. https://extemporelang.github.io/
It differs in aiming to do that within an existing language ecosystem.

PraxisLIVE is "just" an IDE with graphical representation of the
PraxisCORE runtime.

Incidentally, if you want to see an example of live-coding Processing
visuals followed by pattern based sequencing in PraxisLIVE, take a
look at this part of my Write Now, Run Anytime talk -
https://youtu.be/3cQ-8wZwsmY?t=944

That project is one of the example templates available in the IDE if
you want to play with it.

Best wishes,

Neil

--
Neil C Smith
Artist & Technologist
www.neilcsmith.net

PraxisLIVE - hybrid visual live programming
for creatives, for programmers, for students, for tinkerers
www.praxislive.org
Message has been deleted

Jean-François Hicter

unread,
Feb 28, 2020, 7:24:36 AM2/28/20
to PraxisLIVE software discussion group
Here is a short demo of what I achieved to do with Processing/Minim: https://www.dropbox.com/s/ybrtm7cvtcrlplb/testScreen?dl=0

I'm not fully satisfied with the quality of sound: it is not crystal clean as it is supposed to be and as I can expect to have with a piece of software like Reaktor. But I'm on Linux, now, and coding instead of plug-in modules, so, forget Reaktor...

So, yes, my main need is to have a perfect sound quality...
Maybe my code is responsible for the additional noise, as I modulate the amplitude and frequency of a pure sine-wave through Processing 60 Hz interface...
I don't really know, here, how works Minim: it seems the wave is 44.1 kHz but the modulations are Processing frameRate frequency...
The video quality is okay for me with Processing, so I guess this is the same with PraxisLIVE...

What are your advise to clean this sh*t up?!

:D

Neil C Smith

unread,
Feb 28, 2020, 7:31:45 AM2/28/20
to Praxis LIVE software discussion group
On Fri, 28 Feb 2020 at 12:22, Jean-François Hicter <hic...@gmail.com> wrote:
> I'm not fully satisfied with the quality of sound: it is not crystal clean as it is supposed to be and as I can expect to have with a piece of software like Reaktor. But I'm on Linux, now, and coding instead of plug-in modules, so, forget Reaktor...

One thing might be PulseAudio - if the PulseAudio resamplers get
involved, eg. because the card is opened at 48kHz and the application
is outputting 44.1kHz this can cause some artefacts.

Straight interface with Jack can be a better option there if possible.

> Maybe my code is responsible of the additional noise, as I modulate the amplitude and frequency of a pure sine-wave through processing 60 Hz interface...

This is one thing PraxisLIVE is designed to do very differently -
handle messaging between the two. All control in an audio graph can
be timed to audio rate. Processing only offers the visual framerate
as an easy way to control things, and there's no proper way of timing
between audio and visual. That 60Hz control rate also doesn't reflect
that the timing between the two is not fixed - audio processing will
drift slightly forward or back from visual processing.

> I don't really know, here, how works Minim: it seems the wave is 44.1 kHz but the modulations are Processing frameRate frequency...
> The video quality is okay for me with Processing, so I guess this is the same with PraxisLIVE...

Maybe. Depends if you're using the P2D or P3D OpenGL renderers in
Processing - PraxisLIVE only offers those.

Jean-François Hicter

unread,
Feb 28, 2020, 7:48:43 AM2/28/20
to praxi...@googlegroups.com
One thing might be PulseAudio - if the PulseAudio resamplers get
involved, eg. because the card is opened at 48kHz and the application
is outputting 44.1kHz this can cause some artefacts.

Straight interface with Jack can be a better option there if possible.

1: I experience very annoying xruns with Jack
2: I don't manage to record the sound with simpleScreenRecorder when I'm using Jack...

But the most dramatic issue are the xruns...
I guess my hardware is responsible and I can nothing to help that...
 
> Maybe my code is responsible of the additional noise, as I modulate the amplitude and frequency of a pure sine-wave through processing 60 Hz interface...

This is one thing PraxisLIVE is designed to do very differently -
handle messaging between the two.  All control in an audio graph can
be timed to audio rate.  Processing only offers the visual framerate
as an easy way to control things, and there's no proper way of timing
between audio and visual.  That 60Hz control rate also doesn't reflect
that the timing between the two is not fixed - audio processing will
drift slightly forward or back from visual processing

That sounds good... :)

Prosperoh

unread,
Mar 11, 2021, 9:06:58 AM3/11/21
to PraxisLIVE discussion group
1: I experience very annoying xruns with Jack
2: I don't manage to record the sound with simpleScreenRecorder when I'm using Jack...

1. Have you tried to increase the latency in the jack server settings? Maybe the latency you are running jack with is too low, and the hardware cannot keep up.
2. I personnally use mhwaveedit, just connect the desired output to mhwaveedit input and it should work.

If you run Linux, in any case I would strongly recommend to use jack for using live audio software.

Neil C Smith

unread,
Mar 11, 2021, 9:15:59 AM3/11/21
to Praxis LIVE software discussion group
Hi,
+1!

Note that the other things to be aware of that's PraxisLIVE specific
with relation to Jack xruns are the Java garbage collector and JIT
compiler.

In v4, opting in to a separate process for audio (particularly
separated from the IDE editor and the Java compiler) keeps the audio
process size and GC time low. In v5, a separate process for audio is
now the default.

The JIT compiler shouldn't normally be an issue unless you're
live-coding intensive low-level algorithms (eg. at the DSP level). If
doing this, there are ways of stopping it being an issue by warming up
the code before it hits the audio graph.

Best wishes,

Neil
Reply all
Reply to author
Forward
0 new messages