pattrstorage to SQL on remote server and back
Dear Max people
I’m working on a project where multiple users upload pattrstorage preset files (either .json or .xml) to a table in sql on a remote server (not within the Max application via SQLite). Some of the information in the file I want to put into a webpage and this is why I want the files put into sql.
Then I want to download those files to a central computer and use them to make a sound installation. I have searched forums and documentation but not getting to far.
I know that jit.uldl will let you up/download to and from a directory but this would be a bit untidy in terms of making the website. I have also looked at net.loadbang-SQL http://www.loadbang.net/space/Software/net.loadbang-SQL
but (unless I’m mistaken) this seems to require installation of drivers etc which would not work for the people doing the uploading.
I know this question covers a lot of technologies here but is there a way to upload to an SQL table from pattrstorage? If so what resources could I access to learn how to do it?
I have a similar request, for a maybe not as complex use. I’d like to be able to connect pattrstorage to SQLite which is buiilt into Max already. The commands for the databases would be the same…
I’d create a table containing all the clients of a pattrstorage as columns. It should be possible to patch this somehow out of pattrstorage, but it would be great to have this option built-in. Connect pattrstorage to a database, and then a save would not store to disk, but store into the database. That way I would be able to keep multiple different pattrstorages and save the state of a patch into a single SQLite file or as you need it into a bigger database like Mysql…
It would also solve a common problem in mixer like setups. If I have a mixer with 12 channels, I’d like to have presets just for the filters, but these should be the same for all channels. Every filter would have a pattrstorage, but would connect to the same table in the database. If I modify the presets in one filter the others would be updated automatically. At the moment I need to save the presets to disk, notify all other channels that something has changed and they need to reload the presets… This is a bit more complicated than necessary…
I agree that what you are describing for pattrstorage would be useful however its not clear why you can’t do everything you have mentioned with one pattrstorage.
I wonder if your comment "commands for the databases would be the same" over looks the issue of talking to SQL on a remote server. Extending your feature request I think it would be very cool if pattrstorage could upload to an SQL database. This would make networked music making very easy and open up a lot of possibilities.
The net.loadbang.sql machinery doesn’t require drivers to be "installed" – it does require the JDBC drivers to be in your Java classpath, but then the rest of the libraries need to be in the classpath already.
FWIW, I’ve just put out a more up-to-date SQL bridge, still using JDBC, but scripted in Clojure: https://github.com/cassiel/maxmsp-clojure-sql
Thanks Nick, sorry but programming jargon like "JDBC drivers to be in your Java classpath" tends to make my head spin. If I where to use the SQL bridge in the app and build it as a standalone that can talk to a remote SQL table will the person using the standalone have to do anything other than use the app?
Hi maxers I just wanted to follow up by sharing what I have found so far.
I’ve been using MySQLJDBC by Mark-David Hosale and it’s pretty straight forward and well documented for those like myself who aren’t expert programmers. If you want to dig into writing java to acces SQL this would be a good place to start.
Many thanks to Mark-David.
A small issue with this object is that you have to use these guys ‘ ‘ in the SQL queries. If you need to spit out several values from a coll into an SQL query its very tricky adding them in.
The net.loadbang objects look very impressive but require a lot more knowledge to use. However many thanks to Nick for his work also.