pythonmidi-devel — Discussion about the development of the modules

Re: [Pythonmidi-devel] Pyrex experiences?

[Jack J. <Jac...@cw...>]

On 30 Oct 2004, at 08:00, Tim Thompson wrote:

>> So, anybody have any interesting experiences with Pyrex?
>
> Pyrex is fabulous, in my experience.

Pyrex is pretty good, but one should keep in mind that it's "yet 
another tool". What I mean is that using pyrex would create a 
dependency on it, and this would mean either that end users (assuming 
they want to or have to install the midi stuff from source) would have 
to install it too, or the source distribution would have to contain the 
pyrex C output files.
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

Re: [Pythonmidi-devel] Pyrex experiences?

[Lennart R. <re...@nu...>]

Tim Thompson wrote:
>>So, anybody have any interesting experiences with Pyrex?
> 
> 
> Pyrex is fabulous, in my experience.  The way it lets
> you seamlessly combine C and python code is almost spooky.
> I've used it for both portaudio and VST-plugin host development.
> 
> BTW, let me encourage your efforts by saying that I would love
> to see some simple and low-level (but complete, with arbitrary sysex)
> MIDI support in python.

Cool, thanks! Yes, I think pyrex ix the way to go. I have some problems 
passing structs by reference for the moment, but other than that it 
seems to work fine.

RE: [Pythonmidi-devel] Pyrex experiences?

[Tim T. <tj...@no...>]

> So, anybody have any interesting experiences with Pyrex?

Pyrex is fabulous, in my experience.  The way it lets
you seamlessly combine C and python code is almost spooky.
I've used it for both portaudio and VST-plugin host development.

BTW, let me encourage your efforts by saying that I would love
to see some simple and low-level (but complete, with arbitrary sysex)
MIDI support in python.

     ...Tim...

Re: [Pythonmidi-devel] And there was much rejoicing!

[Jay V. <jv...@ac...>]

At 17:08 Uhr +0200 29.10.2004, Jack Jansen wrote:
>I had a quick look at the API and it looks pretty decent. Has it
>only been open-sourced recently?
>

no, MidiShare has been around for years.

>>>Unfortunately the tool to do so is so quirky that I
>>>seem to be the only person who's able to drive it:-)
>>what a sucky tool.
>Ah, yes, good idea. Let's start randomly insulting each other:-(
>

hey, i was talking about the tool not you!  if you wrote it, don't 
take offense!

>(For the record: bgen may be quirky, but it has enabled me to almost
>single-handedly open up all major MacOS APIs to Python, and keep
>those interfaces up to date over the last 10 years, from MacOS 7
>straight to MacOS X. So, while quirky I wouldn't call it "sucky").

well, if its gonna be a tool, i'd warrant that more than one person 
should be able to use it.  thats all.  i had no idea you were talking 
about something you have such an investment in, since you brought up 
how hard it is to use ...

-- 

;

Jay Vaughan

Re: [Pythonmidi-devel] And there was much rejoicing!

[Jack J. <Jac...@cw...>]

On 29-okt-04, at 13:40, Jay Vaughan wrote:

>> But if there are more Mac developers,
>
> i'm a mac/unix/embedded developer.  i like darwin a lot.
>
>> and people could point me in
>> the right direction as to which bits of QuickTime or Audio Units
>> would need to be exposed to Python to enable MIDI support I can make
>> those bits available pretty easily:
>
> i don't think you have to -only- do the built-in Apple/MIDI API.  if 
> you do python for midishare, then you get cross-platform MIDI support: 
> MidiShare runs on everything.

If you mean: "you don't have to do anything platform-specific when you 
use MidiShare": that's good news!

I had a quick look at the API and it looks pretty decent. Has it only 
been open-sourced recently?

[...]
>> Unfortunately the tool to do so is so quirky that I
>> seem to be the only person who's able to drive it:-)
>
> what a sucky tool.

Ah, yes, good idea. Let's start randomly insulting each other:-(

(For the record: bgen may be quirky, but it has enabled me to almost 
single-handedly open up all major MacOS APIs to Python, and keep those 
interfaces up to date over the last 10 years, from MacOS 7 straight to 
MacOS X. So, while quirky I wouldn't call it "sucky").
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

Re: [Pythonmidi-devel] Pyrex experiences?

[Lennart R. <re...@nu...>]

Jay Vaughan wrote:
> i don't personally think that C-code to interface to python objects is 
> that complex.  i've been coding in C since '85 but only hacking python 
> for 2 or 3 years, so maybe thats just me.

Well, I have been avoiding C and C++ since 96 so I'm beginning to forget 
it, and C-extentions bring up frightful memories. ;)

No, it ain't that complex. But it takes very careful driving, I don't 
understand all the details which annoy me, and then going from just 
wrapping methods to making objects didn't seem very inviting. ;) So I'll 
go for Pyrex first and see if that works.

> and anyway, its already been done for MidiShare:
> 
> /src/midishare/lang/python/src/Midi.c
> 
> and
> 
> /src/midishare/lang/python/src/MidiPlayer.c

Yeah, yeah, I know you like MidiShare. ;) I'm sure it's great. But one 
of the original objectives when I started this was to make something 
simple and low-level that did not require third-party libraries.

I notice that the interest in this seem frigthfully low, but I don't 
care. I'll just have to do it all myself. No problems, it will just take 
very long. :)

Re: [Pythonmidi-devel] Pyrex experiences?

[Jay V. <jv...@ac...>]

>The solution to this is supposed to be to write the whole python
>object in C, instead of just wrapping the c methods in a python
>object. C objects do get properly deallocated when a program exits,
>I'm told. Now, that means that the C code suddenly gets MUCH more
>complex (and it wasn't exactly trivial before either) so I'm gonna
>look at doing this in Pyrex.

i don't personally think that C-code to interface to python objects 
is that complex.  i've been coding in C since '85 but only hacking 
python for 2 or 3 years, so maybe thats just me.

and anyway, its already been done for MidiShare:

/src/midishare/lang/python/src/Midi.c

and

/src/midishare/lang/python/src/MidiPlayer.c


.. already cross the python/midi bridge.

-- 

;

Jay Vaughan

Re: [Pythonmidi-devel] And there was much rejoicing!

[Jay V. <jv...@ac...>]

>But if there are more Mac developers,

i'm a mac/unix/embedded developer.  i like darwin a lot.

>and people could point me in
>the right direction as to which bits of QuickTime or Audio Units
>would need to be exposed to Python to enable MIDI support I can make
>those bits available pretty easily:

i don't think you have to -only- do the built-in Apple/MIDI API.  if 
you do python for midishare, then you get cross-platform MIDI 
support: MidiShare runs on everything.

if use use MidiShare for the MIDI abtraction layer, in other words, 
there need not be individual 'fixes' for each platforms' MIDI side.

MidiShare is a clean, well-proven, well-designed, abstract C API.  I 
rank it higher than CoreMIDI for plain ol' MIDI hacking fun. 
CoreMIDI implies CoreEverythingElse, yuck.  I like Darwin, and since 
its Darwin, I don't -need- to use the AppleAPI's for everything..

>the Python interfaces to the
>MacOS API's can be generated from the Apple headers with not too
>much effort.

Do MidiShare first, and you get linux/win32/osx MIDI from the get-go.

>Unfortunately the tool to do so is so quirky that I
>seem to be the only person who's able to drive it:-)

what a sucky tool.

-- 

;

Jay Vaughan

[Pythonmidi-devel] Pyrex experiences?

[Lennart R. <re...@nu...>]

A big problem popped up yesterday:

It turns out that a Python objects __del__ does not necessarily get 
called when a program exits. I knew this once, but I had forgotten it.

This means the ports does not get closed unless you specifically call 
close on the objects. This is major bug for a Python program, where the 
garbage collection is supposed to make sure you never have to deallocate 
resources. It's also makes my computer crash. Not immediatly mind you, 
but say, 30 minutes later, or so. XP just silently goes *poof* and 
reboots. NOT fun! (It's probably crappy MIDI drivers that cause this).

The solution to this is supposed to be to write the whole python object 
in C, instead of just wrapping the c methods in a python object. C 
objects do get properly deallocated when a program exits, I'm told. Now, 
that means that the C code suddenly gets MUCH more complex (and it 
wasn't exactly trivial before either) so I'm gonna look at doing this in 
Pyrex.

So, anybody have any interesting experiences with Pyrex?

Re: [Pythonmidi-devel] And there was much rejoicing!

[Lennart R. <re...@nu...>]

Jack Jansen wrote:
> But if there are more Mac developers, and people could point me in the 
> right direction as to which bits of QuickTime or Audio Units would need 
> to be exposed to Python to enable MIDI support I can make those bits 
> available pretty easily: the Python interfaces to the MacOS API's can be 
> generated from the Apple headers with not too much effort. Unfortunately 
> the tool to do so is so quirky that I seem to be the only person who's 
> able to drive it:-)

Well, that should be enough. But of course, I can't point you in that 
direction. ;) Not yet at least. Maybe I'll dig up some Mac documentation 
and look into it later.

//Lennart

Re: [Pythonmidi-devel] And there was much rejoicing!

[Jack J. <Jac...@cw...>]

On 28-okt-04, at 1:13, Lennart Regebro wrote:
>  and how about Mac OS X? Any Mac developer here?

I'm a Mac developer (and, incidentally, responsible for Python on the 
Mac:-). But: I have very little time for Python work right now, let 
alone PythonMIDI work:-(

But if there are more Mac developers, and people could point me in the 
right direction as to which bits of QuickTime or Audio Units would need 
to be exposed to Python to enable MIDI support I can make those bits 
available pretty easily: the Python interfaces to the MacOS API's can 
be generated from the Apple headers with not too much effort. 
Unfortunately the tool to do so is so quirky that I seem to be the only 
person who's able to drive it:-)
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

Re: [Pythonmidi-devel] And there was much rejoicing!

[Lennart R. <re...@nu...>]

Jay Vaughan wrote:
> At 1:13 Uhr +0200 28.10.2004, Lennart Regebro wrote:
> 
>> Welcome to this nice, clean spring-fresh (or autumn-fresh, rather) list.
> 
> the trees are orange here in the fat RE, bit strange to me really. not 
> used to it.

Looks nice though!

>> So, next step should be having a unix implementation of similarily
>> basic level, and then a unification of these APIs. Also the
>> low-level API needs to be extended with SysEx support. At the moment
>> only short messages can be sent. I'm not sure ALSA distinguishes
>> between them.
> 
> You're pretty sure about ALSA for MIDI?

I know ALSA does MIDI, yes. But other than that i'm not sure I 
understand then question.

> Me, personally, I'd be happy to see midishare support added to python, 
> not just ALSA.  So any work on making pythonmidi less crufty in the ALSA 
> usage is happy to me!  :)

> there already is midishare support in python, just not that much python 
> midi applications being written .. seems like the right language for the 
> job to me though.

MidiShare is a big library. Nothing wrong with that, but as you mention 
there are already python wrappers for it. It is aimed for writing 
sequencers and stuff like that, which is cool, but it seems to me that 
this is overkill for most applications.

However, I just noticed that since two weeks ago, Midishare is also on 
source forge, which is great!

Re: [Pythonmidi-devel] And there was much rejoicing!

[Jay V. <jv...@ac...>]

At 1:13 Uhr +0200 28.10.2004, Lennart Regebro wrote:
>Welcome to this nice, clean spring-fresh (or autumn-fresh, rather) list.

the trees are orange here in the fat RE, bit strange to me really. 
not used to it.

>So, next step should be having a unix implementation of similarily
>basic level, and then a unification of these APIs. Also the
>low-level API needs to be extended with SysEx support. At the moment
>only short messages can be sent. I'm not sure ALSA distinguishes
>between them.

You're pretty sure about ALSA for MIDI?

>Does anybody else know? and how about Mac OS X? Any Mac developer here?
>I assume OSS support has lost it's interest now with ALSA, right?

Me, personally, I'd be happy to see midishare support added to 
python, not just ALSA.  So any work on making pythonmidi less crufty 
in the ALSA usage is happy to me!  :)

there already is midishare support in python, just not that much 
python midi applications being written .. seems like the right 
language for the job to me though.

-- 

;

Jay Vaughan

[Pythonmidi-devel] And there was much rejoicing!

[Lennart R. <le...@re...>]

Welcome to this nice, clean spring-fresh (or autumn-fresh, rather) list.

Although this list ends in "devel" and is ment for the discussion of the 
development of PythonMIDI, you are free to discuss anything remotely 
related for the moment, becuase this is the only list there is. ;-)
After a first proper release has been done I guess a "user" list should 
be created as well.

So, next step should be having a unix implementation of similarily basic 
level, and then a unification of these APIs. Also the low-level API 
needs to be extended with SysEx support. At the moment only short 
messages can be sent. I'm not sure ALSA distinguishes between them.
Does anybody else know? and how about Mac OS X? Any Mac developer here?

I assume OSS support has lost it's interest now with ALSA, right?

//Lennart