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]

Levi Campbell wrote:

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]

Levi Campbell wrote:

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]

On Fri, 03 Feb 2006 02:35:56 +0100
Ivan Voras <ivoras@__-fer.hr-__> wrote:

Levi Campbell wrote:

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

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

--
Terry Hancock (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

[simonwittber]

Levi Campbell wrote:

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]

si**********@gmail.com wrote:

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]

Ivan Voras wrote:

si**********@gmail.com wrote:

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... :)

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]

Fuzzyman wrote:

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]

Ivan Voras wrote:

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.

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]

On 2006-02-03, Ivan Voras <ivoras@__yahoo__.com_> wrote:

si**********@gmail.com wrote:

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... :)

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 grante Yow! Should I get
at locked in the PRINCICAL'S
visi.com OFFICE today -- or have
a VASECTOMY??

[Grant Edwards]

On 2006-02-03, Fuzzyman <fu******@gmail.com> wrote:

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.

--
Grant Edwards grante Yow! Dehydrated EGGS are
at STREWN across ROULETTE
visi.com TABLES...

[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.


--
Andrew Gwozdziewycz <ap****@gmail.com>
http://ihadagreatview.org
http://plasticandroid.org

[Tom Anderson]

On Fri, 3 Feb 2006, Ivan Voras wrote:

Levi Campbell wrote:

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?

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

--
Throw bricks at lawyers if you can!

[Ivan Voras]

Grant Edwards wrote:

On 2006-02-03, Ivan Voras <ivoras@__yahoo__.com_> wrote:

si**********@gmail.com wrote:

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... :)

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]

On Fri, 03 Feb 2006 20:03:01 +0100
Ivan Voras <iv****@fer.hr> wrote:

Grant Edwards wrote:

On 2006-02-03, Ivan Voras <ivoras@__yahoo__.com_> wrote:

si**********@gmail.com wrote:

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... :)

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. --

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
--
Terry Hancock (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

[Grant Edwards]

On 2006-02-03, Ivan Voras <iv****@fer.hr> wrote:

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... :)

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.

People who say what?

--
Grant Edwards grante Yow! Do you need
at any MOUTH-TO-MOUTH
visi.com resuscitation?

[Ivan Voras]

Terry Hancock wrote:

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]

Fredrik Lundh wrote:

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]

Ivan Voras wrote:

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]

Ivan Voras wrote:

Ivan Voras wrote:

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.

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