would it be feasable to write python DJing software

[Levi Campbell]

Hi, I'm thinking about writing a system for DJing in python, but I'm
not sure if Python is fast enough to handle the realtime audio needed
for DJing, could a guru shed some light on this subject and tell me if
this is doable or if I'm out of my fscking mind?

 

[Farshid Lashkari]

Hi, I'm thinking about writing a system for DJing in python, but I'm
not sure if Python is fast enough to handle the realtime audio needed
for DJing, could a guru shed some light on this subject and tell me if
this is doable or if I'm out of my fscking mind?

What do you mean by DJing? Queueing and playing audio files? If so,
python should work fine. Check out the PyMedia library for
playing/mixing audio with python.

-Farshid

 

[Ivan Voras]

Hi, I'm thinking about writing a system for DJing in python, but I'm
not sure if Python is fast enough to handle the realtime audio needed
for DJing, could a guru shed some light on this subject and tell me if
this is doable or if I'm out of my fscking mind?

Any and all mixing would probably happen in some sort of multimedia
library written in C (it would be both clumsy to program and slow to
execute if the calculations of raw samples/bytes were done in python) so
there shouldn't be a noticable performance hit.

 

[Terry Hancock]

Any and all mixing would probably happen in some sort of
multimedia library written in C

Of which more than one exists. You may have some interest in
PyMedia, PyGame (SDL), pyogg, pyvorbis packages.

You might want to try googling for "Python audio libraries",
that appears to turn up some other results.

Note that pyogg/pyvorbis will also give you access to
the embedded metadata in Ogg files, which sounds like it
might be useful in your application.

Cheers,
Terry

 

[simonwittber]

Any and all mixing would probably happen in some sort of multimedia
library written in C (it would be both clumsy to program and slow to
execute if the calculations of raw samples/bytes were done in python) so
there shouldn't be a noticable performance hit.

Actually, manipulating and mixing audio samples can be both fast and
elegant, in Python, if you use Numeric or a similar library.

-Sw.

 

[Ivan Voras]

Actually, manipulating and mixing audio samples can be both fast and
elegant, in Python, if you use Numeric or a similar library.

.... at which point you're actually doing it in C, not pure python...

 

[Fuzzyman]

... at which point you're actually doing it in C, not pure python...

Only in as much as doing anything in Python is *really* doing it in C,
surely ?

Come to that, you're **really** doing it in machine code...

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

 

[Ivan Voras]

Only in as much as doing anything in Python is *really* doing it in C,
surely ?

Come to that, you're **really** doing it in machine code...

I've yet to see someone calling

if a == '5':
print "it's 5"

machine code. It's the distinction on which level the program's logic is
implemented, not at which level it's executed.

 

[Fredrik Lundh]

I've yet to see someone calling

if a == '5':
print "it's 5"

machine code. It's the distinction on which level the program's logic is
implemented, not at which level it's executed.

uhuh? so why did you just argue that

if foo.bar():
bar.aba()

means "doing it in C" if bar and aba happens to be parts of an extension
library ?

</F>

 

[Grant Edwards]

... at which point you're actually doing it in C, not pure python...

If that's the way you want to look at it, there is nothing that
can be done in pure python. Both the built-ins and the basic
operators and sematics are implimented in C. Unless you're
running Jython on a platform that has a hardware JVM, I
suppose. But noboby in this discussion is doing that.

 

[Grant Edwards]

Come to that, you're **really** doing it in machine code...

And probably not the machine code emitted by the assembler but
rather the actual micro-code that's implemented in hardware
that's running a program that implements the VM for the machine
code emitted by the assemblers.

Hell, from the Python point of view it might as well be
tortoises all the way down.

 

[Andrew Gwozdziewycz]

If that's the way you want to look at it, there is nothing that

can be done in pure python. Both the built-ins and the basic
operators and sematics are implimented in C.

What makes python a powerful programming language? It's the fact that
it bundles up all sorts of c-code into a nice easy to use language.
When you write _any_ python, you are taking a peice of c here, a piece
of c here, and when you import a "pure python" module, you're really
just importing more c, because it's all being built from c.

What makes a builtin faster? It's the fact that there's less work to
be done before it's called. As more work needs to get done to find the
builtins that make it possible to run, execution time increases. Plain
and simple.

So, to answer the original posters question, Use python to peice
together the things you need. You're development time will be fast,
and you will probably see some good results.

 

[Tom Anderson]

Perhaps surprisingly, it is:

http://www.python.org/pycon/dc2004/papers/6/

At least, you can certainly mix in realtime in pure python, and can
probably manage some level of effects processing. I'd be skeptical about
decoding MP3 in realtime, but then you don't want to write your own MP3
decoder anyway, and the existing ones you might reuse are all native code.

Any and all mixing would probably happen in some sort of multimedia
library written in C (it would be both clumsy to program and slow to
execute if the calculations of raw samples/bytes were done in python)

Clumsy? Clumsier than C? No, python isn't as good with binary data as it
is with text or objects, but on the whole program scale, it's still miles
ahead of C.

My advice would be to tackle the task in the same way you'd tackle any
other: write it in pure python, then fall back to native code where it's
unavoidable. When i say 'pure python', i don't mean 'not using any native
modules at all', obviously - if someone's written an MP3 decoder, don't
eschew it because it happens to be in C. Also, bear in mind that resorting
to native code doesn't automatically mean writing in C - you can start
doing stuff like moving from representing buffers as lists of ints to
using NumPy arrays, using the functions in the standard audioop module,
whatever; if that's not fast enough, rewrite chunks of the code in pyrex
(a derivative of python that can be compiled to native code, via
translation to C); if it's still not fast enough, go to C.

Oh, and before you start going native, try running your program under
psyco.

tom

 

[Ivan Voras]

If that's the way you want to look at it, there is nothing that
can be done in pure python.

I think people who say that deliberately misunderstand the point. Python
is suitable for some things, not for others. So is C.

 

[Terry Hancock]

I think people who say that deliberately misunderstand the
point. Python is suitable for some things, not for
others. So is C. --

To me, "doing it in C" implies that I must write some C
code.

In this case, that won't be required at all. Everything the
OP wants to do can be done exclusively by writing Python
code. He will, of course, be *using* some extension
libraries which might in turn have been written in C (or
Fortran, assembly language, or ADA for that matter -- but
practically speaking, C).

This will be true whether he uses PyMedia, PyGame, Numeric
or all three.

Indeed, as an implementation matter only the "glue code"
will be interpreted in Python -- but the OP will not have to
write anything but such "glue code".

For me, who no longer writes *any* C code, not having to
write the C code is a big win. And I think this is the PoV
relevant to the OP.

Cheers,
Terry

 

[Grant Edwards]

I think people who say that deliberately misunderstand the
point. Python is suitable for some things, not for others. So
is C.

People who say what?

 

[Ivan Voras]

To me, "doing it in C" implies that I must write some C
code.

Ok, perhaps it is a bit imprecise

In this case, that won't be required at all. Everything the
OP wants to do can be done exclusively by writing Python
code. He will, of course, be *using* some extension
libraries which might in turn have been written in C (or
Fortran, assembly language, or ADA for that matter -- but
practically speaking, C).

This will be true whether he uses PyMedia, PyGame, Numeric
or all three.

This, of course, is what I am talking about. Python is a great glue
language, but not exactly suitable for lots of bit twiddling or DSP by
itself (itself=only with modules from the standard distribution)

 

[Ivan Voras]

uhuh? so why did you just argue that

if foo.bar():
bar.aba()

means "doing it in C" if bar and aba happens to be parts of an extension
library ?

Because "bar and aba happen to be parts of extension library"

 

[Ivan Voras]

Because "bar and aba happen to be parts of extension library"

To end this disussion: I meant "doing it in C" as a colloquial
expression, not a technical one. The expression holds true for every
case where a function/class/module/etc is implemented in a lower-level
language, and "C" was used only as an example.

 

[Fuzzyman]

To end this disussion: I meant "doing it in C" as a colloquial
expression, not a technical one. The expression holds true for every
case where a function/class/module/etc is implemented in a lower-level
language, and "C" was used only as an example.

I think the point we were trying to make, is that even in 'colloquial
terms' there is *no difference* between using a part of the standard
library (e.g. the builtin module md5) and a third party extension
module written in C.

All the logic you actually write is in pure python.

If you write *your own extension module* in C, then you could rightly
be described as doing it in C.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml