Re: [PD] ISO works combining PD and sculpture

[hans w. koch]

i did quite a few (and counting):
mengenlehre: https://www.youtube.com/watch?v=M7CfOGga8gU
clock of fifths (app version,made with mobmuplat): 
https://www.youtube.com/watch?v=l0V57rxAJoA
clock of fifths (installation): https://www.youtube.com/watch?v=I6ef9XVDf9U
shanti: https://www.youtube.com/watch?v=jxhYZCgtVgg

hth, best

hans

> Am 26.10.2020 um 20:54 schrieb bbob :
> 
> for my students, I'm looking for examples of work that combines PD and 
> sculpture (or installations)... i've got a few of the obvious 
> pd-sequencer-triggering-drum-solenoids to show them, what else?  links to 
> artist sites &/or videos appreciated.
> ___
> 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

Re: [PD] ISO works combining PD and sculpture

[wolfgang spahn]

Hi,
a work I did with Thomas Gerwin:
https://wolfgang-spahn.de/doku.php/installation:augen-auf-schlag
Best!
Wolfgang

Am 26.10.20 um 20:54 schrieb bbob:
for my students, I'm looking for examples of work that combines PD and 
sculpture (or installations)... i've got a few of the obvious 
pd-sequencer-triggering-drum-solenoids to show them, what else?  links 
to artist sites &/or videos appreciated.


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list



--

wolfgang spahn___

kastanienalle 85_10435 berlin
__Atelier:__gerichtstrasse 12-13_13347 berlin
__030 39200060__ 0179 7935447
____





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] "find last error" not working for "argument number out of range" errors

[Roman Haefeli]

On Mon, 2020-10-26 at 22:25 +0100, Antoine Rousseau wrote:
> Yes, this has already been reported at:
> https://github.com/pure-data/pure-data/issues/1045
> 
> and a fix is proposed in: 
> https://github.com/pure-data/pure-data/pull/965

Cool. Thanks for the heads-up and the fix!

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] "find last error" not working for "argument number out of range" errors

[Antoine Rousseau]

Yes, this has already been reported at:
https://github.com/pure-data/pure-data/issues/1045

and a fix is proposed in: https://github.com/pure-data/pure-data/pull/965
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] "find last error" not working for "argument number out of range" errors

[Roman Haefeli]

Hi

"find last error" does not work for "argument number out of range"
errors. Is there a specific reason this is so? Will it always be like
this?

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] MIDI in vanilla?

[Alexandre Torres Porres]

Em seg., 26 de out. de 2020 às 16:59, Roman Haefeli 
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 
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!
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] ISO works combining PD and sculpture

[Miller Puckette via Pd-list]

Look in old Pd Convention proceedings.  For example there's a wonderful
thing called "Moveable Type" in the lobby of the New York Times building.

cheers
Miller

On Mon, Oct 26, 2020 at 03:54:37PM -0400, bbob wrote:
> for my students, I'm looking for examples of work that combines PD and
> sculpture (or installations)... i've got a few of the obvious
> pd-sequencer-triggering-drum-solenoids to show them, what else?  links to
> artist sites &/or videos appreciated.

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!Q_VyJOb19b-gQWsJN6TX3nwS-4MiWrb0FQ8Q9QlNOy3zxvHGI0-w2arQphLj$
>  




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] MIDI in vanilla?

[Roman Haefeli]

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



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] ISO works combining PD and sculpture

[bbob]

for my students, I'm looking for examples of work that combines PD and
sculpture (or installations)... i've got a few of the obvious
pd-sequencer-triggering-drum-solenoids to show them, what else?  links to
artist sites &/or videos appreciated.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] MIDI in vanilla?

[Dan Wilcox]

Many advantages such as metadata, etc. If it seems hard to use, try my 
[c_midiplay] wrapper in https://github.com/danomatika/rc-patches 


> On Oct 26, 2020, at 4:31 PM, pd-list-requ...@lists.iem.at wrote:
> 
>> 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?


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] MIDI in vanilla?

[Alexandre Torres Porres]

Em seg., 26 de out. de 2020 às 13:47, Christof Ressi 
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 <
> i...@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-l...@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
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] MIDI in vanilla?

[Christof Ressi]

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 
mailto:i...@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

Re: [PD] MIDI in vanilla?

[Christof Ressi]

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 
mailto:i...@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

Re: [PD] MIDI in vanilla?

[Alexandre Torres Porres]

Em seg., 26 de out. de 2020 às 10:09, Christof Ressi 
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 :)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] MIDI in vanilla?

[Alexandre Torres Porres]

Em seg., 26 de out. de 2020 às 08:12, Christof Ressi 
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

Re: [PD] MIDI in vanilla?

[João Pais]

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

Re: [PD] MIDI in vanilla?

[Christof Ressi]

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


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] MIDI in vanilla?

[Josh Moore]

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  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-l...@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
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] MIDI in vanilla?

[Christof Ressi]

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

Re: [PD] MIDI in vanilla?

[Roman Haefeli]

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


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list