I have posted my external for reading midi files here:
http://puredata.info/Members/martinrp
There is code and a compiled dll for windoze as well as a shell script to compile it for lignux, and a help patch. Should work on OSX too with slight changes (define _BIG_ENDIAN for ppc).
Midifile reads type 0 and 1 SMF (.mid) files and may work on type 2; it should ignore any non-standard meta codes. Please let me know how you got it to crash ;) Write functionality may be forthcoming in a few weeks...
Martin
Hello,
I would love to try this out but I don't have the applications and knowledge necessary to compile this on osx. Is there a version I could just dump in my extras folder kicking around somewhere?
thanks, alex
On Lundi, octobre 31, 2005, at 02:17 pm, Martin Peach wrote:
I have posted my external for reading midi files here:
http://puredata.info/Members/martinrp
There is code and a compiled dll for windoze as well as a shell script to compile it for lignux, and a help patch. Should work on OSX too with slight changes (define _BIG_ENDIAN for ppc).
Midifile reads type 0 and 1 SMF (.mid) files and may work on type 2; it should ignore any non-standard meta codes. Please let me know how you got it to crash ;) Write functionality may be forthcoming in a few weeks...
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi, trying to compile this on OS X. Don't really know what I'm doing
but got it to compile and now it gives me errors that look like this:
Opened /Users/palli/downloads/Chestnuts_Roasting.mid
Header chunk type: MThd
Header chunk length: 100663296
error: midifile_read_header_chunk: bad file format: bad header chunk
length
Regardless of what I open, it always looks identical except for the
name of the file. Any ideas?
Pall
On 31.10.2005, at 14:17, Martin Peach wrote:
I have posted my external for reading midi files here:
http://puredata.info/Members/martinrp
There is code and a compiled dll for windoze as well as a shell
script to compile it for lignux, and a help patch. Should work on
OSX too with slight changes (define _BIG_ENDIAN for ppc).Midifile reads type 0 and 1 SMF (.mid) files and may work on type
2; it should ignore any non-standard meta codes. Please let me know how you got it to crash ;) Write functionality may be forthcoming in a few weeks...Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- Pall Thayer palli@pallit.lhi.is http://www.this.is/pallit
You need to add a line in midifile.c where it has: // if PPC, define _BIG_ENDIAN put this: #define _BIG_ENDIAN If that doesn't work, there is a bug in my byteswapping code or the file isn't a midi file.
Martin
Pall Thayer wrote:
Hi, trying to compile this on OS X. Don't really know what I'm doing
but got it to compile and now it gives me errors that look like this:Opened /Users/palli/downloads/Chestnuts_Roasting.mid Header chunk type: MThd Header chunk length: 100663296 error: midifile_read_header_chunk: bad file format: bad header chunk
lengthRegardless of what I open, it always looks identical except for the
name of the file. Any ideas?Pall
On 31.10.2005, at 14:17, Martin Peach wrote:
I have posted my external for reading midi files here:
http://puredata.info/Members/martinrp
There is code and a compiled dll for windoze as well as a shell
script to compile it for lignux, and a help patch. Should work on
OSX too with slight changes (define _BIG_ENDIAN for ppc).Midifile reads type 0 and 1 SMF (.mid) files and may work on type 2; it should ignore any non-standard meta codes. Please let me know how you got it to crash ;) Write functionality may be forthcoming in a few weeks...
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- Pall Thayer palli@pallit.lhi.is http://www.this.is/pallit
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
...and also undefine MSW... change #define MSW to //define MSW Martin Peach wrote:
You need to add a line in midifile.c where it has: // if PPC, define _BIG_ENDIAN put this: #define _BIG_ENDIAN If that doesn't work, there is a bug in my byteswapping code or the file isn't a midi file.
Martin
Pall Thayer wrote:
Hi, trying to compile this on OS X. Don't really know what I'm doing
but got it to compile and now it gives me errors that look like this:Opened /Users/palli/downloads/Chestnuts_Roasting.mid Header chunk type: MThd Header chunk length: 100663296 error: midifile_read_header_chunk: bad file format: bad header chunk
lengthRegardless of what I open, it always looks identical except for the
name of the file. Any ideas?Pall
On 31.10.2005, at 14:17, Martin Peach wrote:
I have posted my external for reading midi files here:
http://puredata.info/Members/martinrp
There is code and a compiled dll for windoze as well as a shell
script to compile it for lignux, and a help patch. Should work on
OSX too with slight changes (define _BIG_ENDIAN for ppc).Midifile reads type 0 and 1 SMF (.mid) files and may work on type
2; it should ignore any non-standard meta codes. Please let me know how you got it to crash ;) Write functionality may be forthcoming in a few weeks...Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- Pall Thayer palli@pallit.lhi.is http://www.this.is/pallit
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Here's the code I've edited:
// if PPC, define _BIG_ENDIAN
#define _BIG_ENDIAN
/*#ifdef MSW #define EXPORT_SHARED __declspec(dllexport) #else*/ #define EXPORT_SHARED //#endif #define NO_MORE_ELEMENTS 0xFFFFFFFF
define MSW is commented out in the code so I would guess that my
commenting out the ifdef MSW stuff doesn't really change anything.
defining _BIG_ENDIAN gives me the following warning:
midifile.c:30:1: warning: "_BIG_ENDIAN" redefined <built-in>:1:1: warning: this is the location of the previous definition
Here's my line for compiling:
gcc -o midifile.pd_darwin midifile.c -bundle -bundle_loader ../bin/pd
-flat_namespace (maybe this is wrong?)
It gives me a bunch of errors about signedness but from what i
understand, they shouldn't really matter and it's a gcc4 thing.
Still always get the same error in PD when I try loading a midi file.
The file plays fine in quicktime, so it's valid.
Pall
On 8.11.2005, at 13:22, Martin Peach wrote:
...and also undefine MSW... change #define MSW to //define MSW Martin Peach wrote:
You need to add a line in midifile.c where it has: // if PPC, define _BIG_ENDIAN put this: #define _BIG_ENDIAN If that doesn't work, there is a bug in my byteswapping code or
the file isn't a midi file.Martin
Pall Thayer wrote:
Hi, trying to compile this on OS X. Don't really know what I'm
doing but got it to compile and now it gives me errors that look
like this:Opened /Users/palli/downloads/Chestnuts_Roasting.mid Header chunk type: MThd Header chunk length: 100663296 error: midifile_read_header_chunk: bad file format: bad header
chunk lengthRegardless of what I open, it always looks identical except for
the name of the file. Any ideas?Pall
On 31.10.2005, at 14:17, Martin Peach wrote:
I have posted my external for reading midi files here:
http://puredata.info/Members/martinrp
There is code and a compiled dll for windoze as well as a shell
script to compile it for lignux, and a help patch. Should work
on OSX too with slight changes (define _BIG_ENDIAN for ppc).Midifile reads type 0 and 1 SMF (.mid) files and may work on
type 2; it should ignore any non-standard meta codes. Please let me know how you got it to crash ;) Write functionality may be forthcoming in a few weeks...Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http:// lists.puredata.info/ listinfo/pd-list
-- Pall Thayer palli@pallit.lhi.is http://www.this.is/pallit
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- Pall Thayer palli@pallit.lhi.is http://www.this.is/pallit
hi Martin,
Pall Thayer wrote:
Here's the code I've edited:
// if PPC, define _BIG_ENDIAN
#define _BIG_ENDIAN
/*#ifdef MSW
...
you could escape the config hell at the expense of adding a single condition (which is not much in a file reading code). See Miller's g_array.c, garray_ambigendian(). The flag can be saved in a static variable during class setup.
Btw, there is a midi file reader and writer in cyclone (it is called seq). Being its maintainer, but without an easy access to a big-endian machine, I wonder if it works there...
Krzysztof
hi Krzysztof,
I read:
Btw, there is a midi file reader and writer in cyclone (it is called seq). Being its maintainer, but without an easy access to a big-endian machine, I wonder if it works there...
it does (only tested on linux/ppc)
lg
x
hello,
i need help with a maths problem... i am trying to plot a cumulative distribution curve to weight random. I have a [random] that feeds into a chain of [moses], sililar to the markov chain example but what i want to do is have a table dump into the right inlet of each moses changing the weighting. so far so good. what i need help with is the curve which needs to make it more likely for the next result to be near the same position. the attatched patch has an array with the sort of function it should be... like an s stetched at both ends... is there a way i can do this with expr? or am i going to have to type out a list for each state? i'm sure this is probably quite a simple maths problem... but beyond me... or other ideas? might it be simpler to have a longer array with the curve is then plotted at different points back into the array... but considering i'm probably going to have 16+ of these and other stuff i want to make it as simple as possible....
thanks in advance and apologies for rambling a bit..
pete
hi,
the curve in the array window looks like a half sine wave. try:
(cos(x) + 1) * c with x inside the range -Pi to 0 and c is a constant that defines the output range of the curve 0 to c ...
will look similar to you plot ...
good luck, tebjan
pete mcpartlan schrieb:
hello,
i need help with a maths problem... i am trying to plot a cumulative distribution curve to weight random. I have a [random] that feeds into a chain of [moses], sililar to the markov chain example but what i want to do is have a table dump into the right inlet of each moses changing the weighting. so far so good. what i need help with is the curve which needs to make it more likely for the next result to be near the same position. the attatched patch has an array with the sort of function it should be... like an s stetched at both ends... is there a way i can do this with expr? or am i going to have to type out a list for each state? i'm sure this is probably quite a simple maths problem... but beyond me... or other ideas? might it be simpler to have a longer array with the curve is then plotted at different points back into the array... but considering i'm probably going to have 16+ of these and other stuff i want to make it as simple as possible....
thanks in advance and apologies for rambling a bit..
pete
(cos(x) + 1) * c with x inside the range -Pi to 0 and c is a constant that defines the output range of the curve 0 to c ...
sorry, the output range will be 0 to 2*c ... because the cos range -1 to 1 gets shifted upwards by the +1 to 0..2 and c scales this range ...
pete mcpartlan schrieb:
hello,
i need help with a maths problem... i am trying to plot a cumulative distribution curve to weight random. I have a [random] that feeds into a chain of [moses], sililar to the markov chain example but what i want to do is have a table dump into the right inlet of each moses changing the weighting. so far so good. what i need help with is the curve which needs to make it more likely for the next result to be near the same position. the attatched patch has an array with the sort of function it should be... like an s stetched at both ends... is there a way i can do this with expr? or am i going to have to type out a list for each state? i'm sure this is probably quite a simple maths problem... but beyond me... or other ideas? might it be simpler to have a longer array with the curve is then plotted at different points back into the array... but considering i'm probably going to have 16+ of these and other stuff i want to make it as simple as possible....
thanks in advance and apologies for rambling a bit..
pete
thanks Tebjan,
but...its not half a cosine because it has to flatten out at both ends.
and secondly i have no idea how to take an equation like that and implement that in pd... maybe i didnt explain that i'm not too good at all that maths stuff...
thanks,
pete
Tebjan Halm wrote:
(cos(x) + 1) * c with x inside the range -Pi to 0 and c is a constant that defines the output range of the curve 0 to c ...
sorry, the output range will be 0 to 2*c ... because the cos range -1 to 1 gets shifted upwards by the +1 to 0..2 and c scales this range ...
pete mcpartlan schrieb:
hello,
i need help with a maths problem... i am trying to plot a cumulative distribution curve to weight random. I have a [random] that feeds into a chain of [moses], sililar to the markov chain example but what i want to do is have a table dump into the right inlet of each moses changing the weighting. so far so good. what i need help with is the curve which needs to make it more likely for the next result to be near the same position. the attatched patch has an array with the sort of function it should be... like an s stetched at both ends... is there a way i can do this with expr? or am i going to have to type out a list for each state? i'm sure this is probably quite a simple maths problem... but beyond me... or other ideas? might it be simpler to have a longer array with the curve is then plotted at different points back into the array... but considering i'm probably going to have 16+ of these and other stuff i want to make it as simple as possible....
thanks in advance and apologies for rambling a bit..
pete
Are you just looking to produce a bell curve aka normal/gaussian distibution? Because [;tabname cosinesum 512 1 1( does that just fine.
homepage: http://www.davidgolightly.net
From: pete mcpartlan petemcpartlan@yahoo.co.uk To: Tebjan Halm tebjan@gmx.de, pd-list pd-list@iem.at Subject: Re: [PD] cumulative distribution? Date: Wed, 09 Nov 2005 15:52:27 +0000
thanks Tebjan,
but...its not half a cosine because it has to flatten out at both ends.
and secondly i have no idea how to take an equation like that and implement that in pd... maybe i didnt explain that i'm not too good at all that maths stuff...
thanks,
pete
Tebjan Halm wrote:
(cos(x) + 1) * c with x inside the range -Pi to 0 and c is a constant that defines the output range of the curve 0 to c ...
sorry, the output range will be 0 to 2*c ... because the cos range -1 to 1 gets shifted upwards by the +1 to 0..2 and c scales this range ...
pete mcpartlan schrieb:
hello,
i need help with a maths problem... i am trying to plot a cumulative distribution curve to weight random. I have a [random] that feeds into a chain of [moses], sililar to the markov chain example but what i want to do is have a table dump into the right inlet of each moses changing the weighting. so far so good. what i need help with is the curve which needs to make it more likely for the next result to be near the same position. the attatched patch has an array with the sort of function it should be... like an s stetched at both ends... is there a way i can do this with expr? or am i going to have to type out a list for each state? i'm sure this is probably quite a simple maths problem... but beyond me... or other ideas? might it be simpler to have a longer array with the curve is then plotted at different points back into the array... but considering i'm probably going to have 16+ of these and other stuff i want to make it as simple as possible....
thanks in advance and apologies for rambling a bit..
pete
--
www.140worthing.karoo.net =-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OK, it was my code :( I've just uploaded a new midifile.c to: http://puredata.info/Members/martinrp You no longer need to worry about endianness, I realized that the code for variable length values is portable and doesn't need to be reversed for ppc. (at least I think so...). Please let me know how it goes on OSX. The MSW thing is a hack because I don't use a makefile. Pure Data source code uses MSW or NT to identify that OS, so midifile.c should build on Windows with the same setup as for any other external.
Martin
Pall Thayer wrote:
Here's the code I've edited:
// if PPC, define _BIG_ENDIAN
#define _BIG_ENDIAN
/*#ifdef MSW #define EXPORT_SHARED __declspec(dllexport) #else*/ #define EXPORT_SHARED //#endif #define NO_MORE_ELEMENTS 0xFFFFFFFF
define MSW is commented out in the code so I would guess that my
commenting out the ifdef MSW stuff doesn't really change anything.
defining _BIG_ENDIAN gives me the following warning:midifile.c:30:1: warning: "_BIG_ENDIAN" redefined <built-in>:1:1: warning: this is the location of the previous definition
Here's my line for compiling:
gcc -o midifile.pd_darwin midifile.c -bundle -bundle_loader ../bin/pd
-flat_namespace (maybe this is wrong?)It gives me a bunch of errors about signedness but from what i
understand, they shouldn't really matter and it's a gcc4 thing.Still always get the same error in PD when I try loading a midi file.
The file plays fine in quicktime, so it's valid.Pall
On 8.11.2005, at 13:22, Martin Peach wrote:
...and also undefine MSW... change #define MSW to //define MSW Martin Peach wrote:
You need to add a line in midifile.c where it has: // if PPC, define _BIG_ENDIAN put this: #define _BIG_ENDIAN If that doesn't work, there is a bug in my byteswapping code or the file isn't a midi file.
Martin
Pall Thayer wrote:
Hi, trying to compile this on OS X. Don't really know what I'm
doing but got it to compile and now it gives me errors that look
like this:Opened /Users/palli/downloads/Chestnuts_Roasting.mid Header chunk type: MThd Header chunk length: 100663296 error: midifile_read_header_chunk: bad file format: bad header
chunk lengthRegardless of what I open, it always looks identical except for
the name of the file. Any ideas?Pall
On 31.10.2005, at 14:17, Martin Peach wrote:
I have posted my external for reading midi files here:
http://puredata.info/Members/martinrp
There is code and a compiled dll for windoze as well as a shell
script to compile it for lignux, and a help patch. Should work
on OSX too with slight changes (define _BIG_ENDIAN for ppc).Midifile reads type 0 and 1 SMF (.mid) files and may work on
type 2; it should ignore any non-standard meta codes. Please let me know how you got it to crash ;) Write functionality may be forthcoming in a few weeks...Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http:// lists.puredata.info/ listinfo/pd-list
-- Pall Thayer palli@pallit.lhi.is http://www.this.is/pallit
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- Pall Thayer palli@pallit.lhi.is http://www.this.is/pallit
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hi, martin
on Pd version 0.38.3 (XP) i can't load your compiled "midifile.dll" although it's in the search path.
i downloaded it from here:
http://puredata.info/Members/martinrp
and the .dll version seems to be the latest.
am i missing something. do i need another version of PD for this to work under XP ?
any help appreciated
ciao
oliver
Martin Peach wrote:
OK, it was my code :( I've just uploaded a new midifile.c to: http://puredata.info/Members/martinrp You no longer need to worry about endianness, I realized that the code for variable length values is portable and doesn't need to be reversed for ppc. (at least I think so...). Please let me know how it goes on OSX. The MSW thing is a hack because I don't use a makefile. Pure Data source code uses MSW or NT to identify that OS, so midifile.c should build on Windows with the same setup as for any other external.
Martin
Pall Thayer wrote:
Here's the code I've edited:
// if PPC, define _BIG_ENDIAN
#define _BIG_ENDIAN
/*#ifdef MSW #define EXPORT_SHARED __declspec(dllexport) #else*/ #define EXPORT_SHARED //#endif #define NO_MORE_ELEMENTS 0xFFFFFFFF
define MSW is commented out in the code so I would guess that my
commenting out the ifdef MSW stuff doesn't really change anything.
defining _BIG_ENDIAN gives me the following warning:midifile.c:30:1: warning: "_BIG_ENDIAN" redefined <built-in>:1:1: warning: this is the location of the previous definition
Here's my line for compiling:
gcc -o midifile.pd_darwin midifile.c -bundle -bundle_loader ../bin/pd
-flat_namespace (maybe this is wrong?)It gives me a bunch of errors about signedness but from what i
understand, they shouldn't really matter and it's a gcc4 thing.Still always get the same error in PD when I try loading a midi file.
The file plays fine in quicktime, so it's valid.Pall
On 8.11.2005, at 13:22, Martin Peach wrote:
...and also undefine MSW... change #define MSW to //define MSW Martin Peach wrote:
You need to add a line in midifile.c where it has: // if PPC, define _BIG_ENDIAN put this: #define _BIG_ENDIAN If that doesn't work, there is a bug in my byteswapping code or the file isn't a midi file.
Martin
Pall Thayer wrote:
Hi, trying to compile this on OS X. Don't really know what I'm
doing but got it to compile and now it gives me errors that look
like this:Opened /Users/palli/downloads/Chestnuts_Roasting.mid Header chunk type: MThd Header chunk length: 100663296 error: midifile_read_header_chunk: bad file format: bad header
chunk lengthRegardless of what I open, it always looks identical except for
the name of the file. Any ideas?Pall
On 31.10.2005, at 14:17, Martin Peach wrote:
I have posted my external for reading midi files here:
http://puredata.info/Members/martinrp
There is code and a compiled dll for windoze as well as a shell
script to compile it for lignux, and a help patch. Should work
on OSX too with slight changes (define _BIG_ENDIAN for ppc).Midifile reads type 0 and 1 SMF (.mid) files and may work on
type 2; it should ignore any non-standard meta codes. Please let me know how you got it to crash ;) Write functionality may be forthcoming in a few weeks...Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http:// lists.puredata.info/ listinfo/pd-list
-- Pall Thayer palli@pallit.lhi.is http://www.this.is/pallit
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- Pall Thayer palli@pallit.lhi.is http://www.this.is/pallit
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Quoting oliver oliver@klingt.org:
hi, martin
on Pd version 0.38.3 (XP) i can't load your compiled "midifile.dll" although it's in the search path.
i downloaded it from here:
http://puredata.info/Members/martinrp
and the .dll version seems to be the latest.
am i missing something. do i need another version of PD for this to work under XP ?
Yes I believe you need pd 0.39 for this because midifile has a list output, which (I think) wasn't in pd before version 0.39.
Martin
also martin, this midifile external looks great. when it works easy on mac os X i wanna take it for a spin. not really in the mood for compiling stuff at the moment though. i'd rather be soldering.
Quoting hard off hard.off@gmail.com:
also martin, this midifile external looks great. when it works easy on mac os X i wanna take it for a spin. not really in the mood for compiling stuff at the moment though. i'd rather be soldering.
I've had enough soldering for the moment, but I don't have a Mac. It would be nice if someone could compile midifile for OSX...it should build like any other external.
Martin