Patchstorage.com


#1

Just stumbled across this site:
http://patchstorage.com/

It could be used as an interim repository for Axoloti patches, possibly?

a|x


#2

looks like it doesnt support Axoloti yet - I just emailed them and suggested they add support, though


#3

Interim? We already have a working solution with github and the integrated client. There's little mention on that site of who they are and what happens to your patches legally once you upload them. I'd rather not upload my code to some nobodies site just because it looks nice.


#4

Probably shouldn't have mentioned it...

a|x


#5

Ah sorry mate. See what others think. :smile:


#6

i think any type of exclusivity is is bad especially at this stage of interest


#7

people are free to use what they like :smile:

though, personally, as a user, Id say Id prefer to go to one place rather than hunting over the internet for patches, and Id prefer a solution thats attached to the UI.

I may (no promises) add http support to the library system in the future, but its unlikely id support an external site explicitly, as Id have no control on them changing things, and breaking any integration built.

finally, Id have thought patchstorage will not be interested in Axoloti, since their focus is pure data ( hence they were interested in Organelle as it uses PD) , would seem a bit odd for them to start branching off to other patchers.
but hey, I might be wrong.... perhaps they want to expand in different directions.


#8

All valid points thetechnobear.
Ultimately, the best solution is going to be one that makes the online library accessible right inside the Patcher.

Patchblocks do this really well, I have to say. Though their hardware is inferior to Axoloti in almost every way, they do seem pretty together on the editor software side of things, both in terms of online library integration, and of the editor UI, which is pretty slick.

Interestingly, their editor can output audio from the host computer, without the Patchblocks hardware being connected. I'm in two minds about whether that's a good thing or not, at the moment.

a|x


#9

their editor looks quite max like, but I've not run it to see what it does on the library side, Id be interested to see this.

yeah, this can be useful... but its extra development work, so question is how often do you develop the patches without the hardware?
generally the axoloti software could be adapted to generate other code e.g. VST or standalone, the issue with that approach is that it wouldn't have the same limitations as the axoloti core (e.g. memory/cpu ) so would be easy to develop something that then couldn't run on the board.
anyway, perhaps a future development... but lots to explore prior to that I think :smile:


#10

The other reason not to do that with the Axo Patcher is that people might decide they want to run it without buying the hardware at all. That's apparently what happened with the Nord Modular G2 demo editor, with audio output, and that even though it was heavily crippled, compared to the hardware.

The fact the USB connection between the Axoloti hardware and my Mac is hugely more reliable than it is with my Patchblocks Eurorack module is a Big Plus, and more than makes up for the possible slight inconvenience of the Axo Patcher not having audio preview without the hardware.

a|x


#11

I can think of occasions when I might want to run the Patcher without the hardware. For example, when messing around with patches on my work computer. They are relatively rare occasions, though.

a|x


#12

As far as I understood patchblocks, they need an emulator because the upload process is slow, and there is no interaction between patcher and hardware after upload. They use an instruction level emulator, rather than targeting native binaries with a compiler.

I think when the target is hardware, it's far more useful to develop patches in-circuit (the Axoloti approach) rather than emulate. You'd need to rewire audio cabling between development and deployment, and the sound quality and latency may be different. Patchblocks: 10 bit audio conversion "it sounds fatter than you expect!", I think it is better not to introduce surprises in sound quality between development and deployment. Emulation GPIO is another can of worms, only doable if it's just some potentiometers, switches, led's.

Back to the original topic, patchstorage.com, I think integrated repository access is far more useful than web browser download, and this development is close to getting released in a regular (non-Test) release. The only feature missing is voting/ranking/commenting on patches.


#13

Excited to hear that, johannes!

Re. Patchblocks: I can see advantages of both your approach and theirs.

For the record, patch-upload to the Patchblock Euro module I have isn't slow. However, the biggest annoyance is the fact you have to physically unplug and replug the harder form the computer every time you want to upload a new patch.

On El Capitan at least, it's also unreliable, so sometimes you have to unplug/replug/press the reset button several time before it's picked up by the Editor.

In fact, there's no direst connection between Editor and hardware, as far as I can see. What the software actually seems to do, is mount a volume on your machine, then save the compiled patch to the volume. When the Patchblocks hardware is restarted, it loads the compiled patch saved to it by the Editor. It's a very simple system, but in my limited experience, has been frustrating and cumbersome in use.

The only areas they have an advantage over Axolotl, in my book are in the form-factor of the hardware (smaller, and takes up fewer HP when converted to Euro, too), and in the slickness of the Editor UI (screenshots one the Mac version below). In every other respect (including as you point out, Johannes) the most important consideration- audio quality, Axolotl is way ahead.

a|x




#14

thanks for the pictures, interesting.
probably discussion of merits of patch blocks etc, better for a different topic (hardware)... I'm personally quite interested to hear about other modular environments...always willing to learn from them, and also recognise the benefits axoloti has too :smile:

anyway, back to patchstorage... of course let us know if patchstorage are interested in axoloti.


#15

conjecture, that line of thinking is hard to care for especially in an open source project

honestly just now becoming aware of the Patchblock...does not look like my thing and the hardware looks pretty weak

excited to hear that!! 1.0.8 working well :]


#16

I'll probably sell my Patchblocks Euro module pretty soon, mostly because of the poor audio quality.

The only reason I haven't already got rid of it is it's taking up relatively little room in my rack at the moment, and my Euxoloti isn't quite up-and-running yet.

a|x


#17

Oh, I mean, the absence of voting/ranking/commenting is the consequence of using git for collaboration.
My phrasing may have suggested this is a planned addition, but it is not.

Ideas about how to integrate that would be welcome though.


#18

@thetechnobear yes, sorry, you're right, arguably a bit OT. PB online library integration is worth mentioning though. I have yet to try the latest Patcher beta, but it does sound like you've got something similar on the way anyway, so I'm definitely looking forward to that.

a|x


#19

Github Issues API for commenting?


#20

patches/objects already contain descriptions, and could potentially be extended for things like tagging

its yet to be decided how hold more dynamic meta data e.g. ranking, voting etc.
(this needs to be done centralised so is a bit different)