Hi, I thought it was best to start this discussion here rather than as a feature request on github.
It feels to me Vanilla should be able to read/write MIDI files, but I wonder how. Any ideas on how this could work in a "vanilla way" (light and simple)?
As for a sequencer, maybe we could use [text] or something. I'm thinking of a way to not create new objects. Perhaps [soundfiler] could handle MIDI files, but that may be pushing it too far.
Well, I hope you get the idea. I wonder if this was ever discussed and if it just never got any attention
cheers Alex
message sent after finishing
I wonder if this was ever discussed and if it just never got any attention
because we already have externals for that...
Em seg., 26 de out. de 2020 às 03:32, Alexandre Torres Porres < porres@gmail.com> escreveu:
Hi, I thought it was best to start this discussion here rather than as a feature request on github.
It feels to me Vanilla should be able to read/write MIDI files, but I wonder how. Any ideas on how this could work in a "vanilla way" (light and simple)?
As for a sequencer, maybe we could use [text] or something. I'm thinking of a way to not create new objects. Perhaps [soundfiler] could handle MIDI files, but that may be pushing it too far.
Well, I hope you get the idea. I wonder if this was ever discussed and if it just never got any attention
cheers Alex
On Mon, 2020-10-26 at 03:32 -0300, Alexandre Torres Porres wrote:
It feels to me Vanilla should be able to read/write MIDI files, but I wonder how. Any ideas on how this could work in a "vanilla way" (light and simple)?
To use Miller's words from another thread, I think reading/writing MIDI files would be an application for which the infrastructure is still missing: reading from/writing to binary files (unless I missed some recent development).
Both would be cool, accessing them from disk directly and load/dump them to/from tables.
Roman
I agree that we really need a way to read/write binary data. I have already thought about doing a PR to add such functionality to graphical arrays. It would be as simple as adding a flag to the [read( and [write( methods.
In theory, it would be possible then to implement a MIDI file reader/writer as a Pd abstraction. But to be honest, I think only a masochist would do that :-)
On the other hand, mrpeach's [midifile] has always served me well and it's one of those things that don't really get obsolete. So I don't think that Pd really needs built-in MIDI file support. After all, even a kitchen-sink language like Supercollider doesn't come with built-in MIDI file support.
Christof
On 26.10.2020 11:11, Roman Haefeli wrote:
On Mon, 2020-10-26 at 03:32 -0300, Alexandre Torres Porres wrote:
It feels to me Vanilla should be able to read/write MIDI files, but I wonder how. Any ideas on how this could work in a "vanilla way" (light and simple)?
To use Miller's words from another thread, I think reading/writing MIDI files would be an application for which the infrastructure is still missing: reading from/writing to binary files (unless I missed some recent development).
Both would be cool, accessing them from disk directly and load/dump them to/from tables.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I think it comes down to PD's horrible selection of array types. Having arrays with multi dimensions that can be a choice between int and float types signed and unsigned without conversion is what you need otherwise you will run into this wall all over the place and you're looking at a c compiler or interpreted language external to make what exists in almost every other language (ie make 16 arrays with 127 dimensions for each note with byte alignment containing n points or whatever) as three lines of code doable on a system that has only 2d arrays and float types.
On Mon, Oct 26, 2020, 4:12 AM Christof Ressi info@christofressi.com wrote:
I agree that we really need a way to read/write binary data. I have already thought about doing a PR to add such functionality to graphical arrays. It would be as simple as adding a flag to the [read( and [write( methods.
In theory, it would be possible then to implement a MIDI file reader/writer as a Pd abstraction. But to be honest, I think only a masochist would do that :-)
On the other hand, mrpeach's [midifile] has always served me well and it's one of those things that don't really get obsolete. So I don't think that Pd really needs built-in MIDI file support. After all, even a kitchen-sink language like Supercollider doesn't come with built-in MIDI file support.
Christof On 26.10.2020 11:11, Roman Haefeli wrote:
On Mon, 2020-10-26 at 03:32 -0300, Alexandre Torres Porres wrote:
It feels to me Vanilla should be able to read/write MIDI files, but I wonder how. Any ideas on how this could work in a "vanilla way" (light and simple)?
To use Miller's words from another thread, I think reading/writing MIDI files would be an application for which the infrastructure is still missing: reading from/writing to binary files (unless I missed some recent development).
Both would be cool, accessing them from disk directly and load/dump them to/from tables.
Roman
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
a choice between int and float types signed and unsigned without conversion is what you need
Many scripting languages have a single number type. The only "problem" with Pd is that this number type is a float and not a double, so it's easy to run into precision issues. But for bytes, a float is large enough ;-) Yes, you waste some space, but who cares?
Also, you can create multidimensional arrays with data structures, if you really need it (yes, it is awkward, but it is certainly possible). On the other hand, if all subarrays are the same size, it is trivial to embed them in a single flat array...
Apart from that, a MIDI file parser is not something you would typically write in a visual programming language. That's why we have a C external for that ;-)
Christof
On 26.10.2020 13:56, Josh Moore wrote:
I think it comes down to PD's horrible selection of array types. Having arrays with multi dimensions that can be a choice between int and float types signed and unsigned without conversion is what you need otherwise you will run into this wall all over the place and you're looking at a c compiler or interpreted language external to make what exists in almost every other language (ie make 16 arrays with 127 dimensions for each note with byte alignment containing n points or whatever) as three lines of code doable on a system that has only 2d arrays and float types.
On Mon, Oct 26, 2020, 4:12 AM Christof Ressi <info@christofressi.com mailto:info@christofressi.com> wrote:
I agree that we really need a way to read/write binary data. I have already thought about doing a PR to add such functionality to graphical arrays. It would be as simple as adding a flag to the [read( and [write( methods. In theory, it would be possible then to implement a MIDI file reader/writer as a Pd abstraction. But to be honest, I think only a masochist would do that :-) On the other hand, mrpeach's [midifile] has always served me well and it's one of those things that don't really get obsolete. So I don't think that Pd really needs built-in MIDI file support. After all, even a kitchen-sink language like Supercollider doesn't come with built-in MIDI file support. Christof On 26.10.2020 11:11, Roman Haefeli wrote:On Mon, 2020-10-26 at 03:32 -0300, Alexandre Torres Porres wrote:It feels to me Vanilla should be able to read/write MIDI files, but I wonder how. Any ideas on how this could work in a "vanilla way" (light and simple)?To use Miller's words from another thread, I think reading/writing MIDI files would be an application for which the infrastructure is still missing: reading from/writing to binary files (unless I missed some recent development). Both would be cool, accessing them from disk directly and load/dump them to/from tables. Roman _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list <https://lists.puredata.info/listinfo/pd-list>_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list <https://lists.puredata.info/listinfo/pd-list>
if multiarrays with data structures are necessary, they already exist in [jmmmp/multiarray]
a choice between int and float types signed and unsigned without conversion
is what you need
Many scripting languages have a single number type. The only "problem" with Pd is that this number type is a float and not a double, so it's easy to run into precision issues. But for bytes, a float is large enough ;-) Yes, you waste some space, but who cares?
Also, you can create multidimensional arrays with data structures, if you really need it (yes, it is awkward, but it is certainly possible). On the other hand, if all subarrays are the same size, it is trivial to embed them in a single flat array...
Apart from that, a MIDI file parser is not something you would typically write in a visual programming language. That's why we have a C external for that ;-)
Christof On 26.10.2020 13:56, Josh Moore wrote:
I think it comes down to PD's horrible selection of array types. Having arrays with multi dimensions that can be a choice between int and float types signed and unsigned without conversion is what you need otherwise you will run into this wall all over the place and you're looking at a c compiler or interpreted language external to make what exists in almost every other language (ie make 16 arrays with 127 dimensions for each note with byte alignment containing n points or whatever) as three lines of code doable on a system that has only 2d arrays and float types.
On Mon, Oct 26, 2020, 4:12 AM Christof Ressi info@christofressi.com wrote:
I agree that we really need a way to read/write binary data. I have already thought about doing a PR to add such functionality to graphical arrays. It would be as simple as adding a flag to the [read( and [write( methods.
In theory, it would be possible then to implement a MIDI file reader/writer as a Pd abstraction. But to be honest, I think only a masochist would do that :-)
On the other hand, mrpeach's [midifile] has always served me well and it's one of those things that don't really get obsolete. So I don't think that Pd really needs built-in MIDI file support. After all, even a kitchen-sink language like Supercollider doesn't come with built-in MIDI file support.
Christof On 26.10.2020 11:11, Roman Haefeli wrote:
On Mon, 2020-10-26 at 03:32 -0300, Alexandre Torres Porres wrote:
It feels to me Vanilla should be able to read/write MIDI files, but I wonder how. Any ideas on how this could work in a "vanilla way" (light and simple)?
To use Miller's words from another thread, I think reading/writing MIDI files would be an application for which the infrastructure is still missing: reading from/writing to binary files (unless I missed some recent development).
Both would be cool, accessing them from disk directly and load/dump them to/from tables.
Roman
Em seg., 26 de out. de 2020 às 10:09, Christof Ressi info@christofressi.com escreveu:
Apart from that, a MIDI file parser is not something you would typically write in a visual programming language. That's why we have a C external for that ;-)
not aware of the challenges but yeah... and hopefully we could have a built in parser :)
Em seg., 26 de out. de 2020 às 08:12, Christof Ressi info@christofressi.com escreveu:
I agree that we really need a way to read/write binary data. I have already thought about doing a PR to add such functionality to graphical arrays. It would be as simple as adding a flag to the [read( and [write( methods.
In theory, it would be possible then to implement a MIDI file reader/writer as a Pd abstraction. But to be honest, I think only a masochist would do that :-)
You mean as it is or with your PR?
On the other hand, mrpeach's [midifile] has always served me well and it's one of those things that don't really get obsolete.
I never used it because the organization of that help file scares me. Does it have any advantages over cyclone/seq?
So I don't think that Pd really needs built-in MIDI file support. After all, even a kitchen-sink language like Supercollider doesn't come with built-in MIDI file support.
But MAX does.
You mean as it is or with your PR?
Generally, most non-trivial programming tasks are a pain to do in a visual programming language.
I never used it because the organization of that help file scares me.
Then let's improve the help file! I have never used [cyclone/seq], so I can't compare, but [midifile] has always worked fine for me.
But MAX does.
MAX also has wiggling cables, so...
The idea of Pd has always been to keep the core as small as possible and extend it with externals/abstractions. Since we already have (at least) two decent MIDI file externals, why do we need to add it to the core?
Being "vanilla only" is not some kind of merit - it just means the author is being afraid of using externals ;-)
Christof
On 26.10.2020 17:13, Alexandre Torres Porres wrote:
Em seg., 26 de out. de 2020 às 08:12, Christof Ressi <info@christofressi.com mailto:info@christofressi.com> escreveu:
I agree that we really need a way to read/write binary data. I have already thought about doing a PR to add such functionality to graphical arrays. It would be as simple as adding a flag to the [read( and [write( methods. In theory, it would be possible then to implement a MIDI file reader/writer as a Pd abstraction. But to be honest, I think only a masochist would do that :-)You mean as it is or with your PR?
On the other hand, mrpeach's [midifile] has always served me well and it's one of those things that don't really get obsolete.I never used it because the organization of that help file scares me. Does it have any advantages over cyclone/seq?
So I don't think that Pd really needs built-in MIDI file support. After all, even a kitchen-sink language like Supercollider doesn't come with built-in MIDI file support.But MAX does.
MAX also has wiggling cables, so...
On a more serious note: Max/MSP is a full blown commercial production environment. You have video playback, graphics programming, a JavaScript interpreter, VST plugin hosting, etc. You can't really compare it to Pd anymore.
Luckily, Pd is very extendable and we can easily write externals for any task imaginable. Also, we have a quite decent package manager. Whenever I develop stuff for Supercollider I'm painfully reminded of this luxury...
So let's resist the desire to put stuff into Pd that can easily be done with an external. And let's get rid of this idea that "vanilla only" is some kind of gold standard.
Christof
On 26.10.2020 16:31, Christof Ressi wrote:
You mean as it is or with your PR?
Generally, most non-trivial programming tasks are a pain to do in a visual programming language.
I never used it because the organization of that help file scares me.
Then let's improve the help file! I have never used [cyclone/seq], so I can't compare, but [midifile] has always worked fine for me.
But MAX does.
MAX also has wiggling cables, so...
The idea of Pd has always been to keep the core as small as possible and extend it with externals/abstractions. Since we already have (at least) two decent MIDI file externals, why do we need to add it to the core?
Being "vanilla only" is not some kind of merit - it just means the author is being afraid of using externals ;-)
Christof
On 26.10.2020 17:13, Alexandre Torres Porres wrote:
Em seg., 26 de out. de 2020 às 08:12, Christof Ressi <info@christofressi.com mailto:info@christofressi.com> escreveu:
I agree that we really need a way to read/write binary data. I have already thought about doing a PR to add such functionality to graphical arrays. It would be as simple as adding a flag to the [read( and [write( methods. In theory, it would be possible then to implement a MIDI file reader/writer as a Pd abstraction. But to be honest, I think only a masochist would do that :-)You mean as it is or with your PR?
On the other hand, mrpeach's [midifile] has always served me well and it's one of those things that don't really get obsolete.I never used it because the organization of that help file scares me. Does it have any advantages over cyclone/seq?
So I don't think that Pd really needs built-in MIDI file support. After all, even a kitchen-sink language like Supercollider doesn't come with built-in MIDI file support.But MAX does.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em seg., 26 de out. de 2020 às 13:47, Christof Ressi info@christofressi.com escreveu:
MAX also has wiggling cables, so...
On a more serious note: Max/MSP is a full blown commercial production environment. You have video playback, graphics programming, a JavaScript interpreter, VST plugin hosting, etc. You can't really compare it to Pd anymore.
I agree, but [seq] has been there forever, before all that, before MSP I believe.
let's get rid of this idea that "vanilla only" is some kind of gold standard.
I'm taking care myself of about 600 externals (cyclone/ELSE/PSYCHO), so yeah, I get that :)
I still thought MIDI File support was something that could be built in ;) and I'm not all happy with the 2 externals around and thinking of investing more on a third one :)
cheers
Christof On 26.10.2020 16:31, Christof Ressi wrote:
You mean as it is or with your PR?
Generally, most non-trivial programming tasks are a pain to do in a visual programming language.
I never used it because the organization of that help file scares me.
Then let's improve the help file! I have never used [cyclone/seq], so I can't compare, but [midifile] has always worked fine for me.
But MAX does.
MAX also has wiggling cables, so...
The idea of Pd has always been to keep the core as small as possible and extend it with externals/abstractions. Since we already have (at least) two decent MIDI file externals, why do we need to add it to the core?
Being "vanilla only" is not some kind of merit - it just means the author is being afraid of using externals ;-)
Christof On 26.10.2020 17:13, Alexandre Torres Porres wrote:
Em seg., 26 de out. de 2020 às 08:12, Christof Ressi < info@christofressi.com> escreveu:
I agree that we really need a way to read/write binary data. I have already thought about doing a PR to add such functionality to graphical arrays. It would be as simple as adding a flag to the [read( and [write( methods.
In theory, it would be possible then to implement a MIDI file reader/writer as a Pd abstraction. But to be honest, I think only a masochist would do that :-)
You mean as it is or with your PR?
On the other hand, mrpeach's [midifile] has always served me well and it's one of those things that don't really get obsolete.
I never used it because the organization of that help file scares me. Does it have any advantages over cyclone/seq?
So I don't think that Pd really needs built-in MIDI file support. After all, even a kitchen-sink language like Supercollider doesn't come with built-in MIDI file support.
But MAX does.
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Mon, 2020-10-26 at 16:31 -0300, Alexandre Torres Porres wrote:
I still thought MIDI File support was something that could be built in ;) and I'm not all happy with the 2 externals around and thinking of investing more on a third one :)
I thought you said you haven't tried [midifile], yet you know it is not good?
Roman
Em seg., 26 de out. de 2020 às 16:59, Roman Haefeli reduzent@gmail.com escreveu:
On Mon, 2020-10-26 at 16:31 -0300, Alexandre Torres Porres wrote:
I still thought MIDI File support was something that could be built in ;) and I'm not all happy with the 2 externals around and thinking of investing more on a third one :)
I thought you said you haven't tried [midifile], yet you know it is not good?
Yeah I haven't, cause it seems complicated (and I made that somewhat clear), and I didn't say "I know it's not good", but if I were to say I have an issue with it, that's it. But I don't have the idea it's bad, on the contrary, it seems to be more powerful and versatile than [seq] for what people are saying to me right now.
Em seg., 26 de out. de 2020 às 16:46, Dan Wilcox danomatika@gmail.com escreveu:
Many advantages such as metadata, etc. If it seems hard to use, try my [c_midiplay] wrapper in https://github.com/danomatika/rc-patches
Thanks, checking on it right now!
-
Alexandre Torres Porres -
Christof Ressi -
Josh Moore -
João Pais -
Roman Haefeli