Hi Christof,
Not MySQL, but I have done it for SQLite3 database. You can find the details of the implementation and the source code from here:
http://onkyo.u-aizu.ac.jp/index.php/software/hrir/
I wonder how difficult would be to make a generic DB driver, an object that connects to any DB, performs SQL send to its input and returns the results in its outlet. Sounds like fun…
Cheers,
Julian.
thanks! I guess I'll directly work with the mysql library, just as you did with sqlite. the C API doesn't look so complicated, actually.
Gesendet: Dienstag, 23. Januar 2018 um 01:00 Uhr Von: "Julián Villegas" villegas.julian@gmail.com An: pd-list@lists.iem.at Betreff: Re: [PD] MySQL Pd external?
Hi Christof,
Not MySQL, but I have done it for SQLite3 database. You can find the details of the implementation and the source code from here:
http://onkyo.u-aizu.ac.jp/index.php/software/hrir/
I wonder how difficult would be to make a generic DB driver, an object that connects to any DB, performs SQL send to its input and returns the results in its outlet. Sounds like fun…
Cheers,
Julian.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2018-01-23 01:40, Christof Ressi wrote:
thanks! I guess I'll directly work with the mysql library, just as you did with sqlite. the C API doesn't look so complicated, actually.
i guess the main issues with an mysql external is that it breaks all realtime constraints. either you make the calls synchronous, then you probably shouldn't do audio in the same thread (and you could have used e.g. a standalone python application in the first place) or you make it asynchronous (happy coding), which is about one message away in pyext.
fgams IOhannes
i guess the main issues with an mysql external is that it breaks all realtime constraints.
so does [soundfiler]. for things like initializing/saving it won't matter, but you're right, constantly polling the DB in the audio thread is probably not a good idea.
which is about one message away in pyext.
yes, but isn't this true for many things we do in Pd? :-D
Gesendet: Dienstag, 23. Januar 2018 um 09:31 Uhr Von: "IOhannes m zmoelnig" zmoelnig@iem.at An: pd-list@lists.iem.at Betreff: Re: [PD] MySQL Pd external?
On 2018-01-23 01:40, Christof Ressi wrote:
thanks! I guess I'll directly work with the mysql library, just as you did with sqlite. the C API doesn't look so complicated, actually.
i guess the main issues with an mysql external is that it breaks all realtime constraints. either you make the calls synchronous, then you probably shouldn't do audio in the same thread (and you could have used e.g. a standalone python application in the first place) or you make it asynchronous (happy coding), which is about one message away in pyext.
fgams IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2018-01-23 11:05, Christof Ressi wrote:
i guess the main issues with an mysql external is that it breaks all realtime constraints.
so does [soundfiler]. for things like initializing/saving it won't matter, but you're right, constantly polling the DB in the audio thread is probably not a good idea.
which is about one message away in pyext.
yes, but isn't this true for many things we do in Pd? :-D
oh definitely.
i'm not trying to prevent a [mysql] external.
however, from my very long lasting memory on and of the pd-list, i do remember that the blocking issue was indeed mentioned and discussed in conjunction with "some SQL" external. some things change, but some things don't.
fgasdmr IOhannes
thanks for mentioning it. there are some non-blocking mysql client implementations I could have a look at but first I'll try the blocking version and see how it performs.
Gesendet: Dienstag, 23. Januar 2018 um 11:21 Uhr Von: "IOhannes m zmoelnig" zmoelnig@iem.at An: pd-list@lists.iem.at Betreff: Re: [PD] MySQL Pd external?
On 2018-01-23 11:05, Christof Ressi wrote:
i guess the main issues with an mysql external is that it breaks all realtime constraints.
so does [soundfiler]. for things like initializing/saving it won't matter, but you're right, constantly polling the DB in the audio thread is probably not a good idea.
which is about one message away in pyext.
yes, but isn't this true for many things we do in Pd? :-D
oh definitely.
i'm not trying to prevent a [mysql] external.
however, from my very long lasting memory on and of the pd-list, i do remember that the blocking issue was indeed mentioned and discussed in conjunction with "some SQL" external. some things change, but some things don't.
fgasdmr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list