How come there’s no Pisound category on Patchstorage?
No need is there? It’s standard rPI/Pure data … only exception I gueas are externals, but if patcher could supply multiple platforms.
it’s kind of same as Mac/windows , patches are cross platform but externals not necessarily so.
Organelle/Bela are different since these are using ‘extensions’ , so patches would likely need altering to work.
Perhaps it would have been better if PS had puredata as a category, and platforms were just tags.
I do think that a Pisound category would be useful in the light of how the app works. Patches do profit from being made in a standard way (regarding MIDI mapping) and ideally should come with a .yml file and a picture. Also it would be really helpful if they are actually designed to work with Pisound.
So while it’s still pretty much vanilla Pd, there’s some things specific to Pisound.
Yeah indeed, that is a good point. Even more in combination with what I said above. Making all Pd one category and then differentiating it between the platform it’s been designed to run on would really make sense. Most Pd patches can be adapted to work on another platform with more or less little effort (I adapted your CLDS for Organelle patch for the Pisound and it wasn’t much work)
yeah, I think the points you make, illustrate the underlying issue really well…
from what i see in the Organelle community, you have different ‘user’ types
- those that just want to download a patch and run it
they either cannot or do not want to edit it - those that are willing to take a patch, and use it as a starting point, and convert / develop it.
(and of course, users might be a mix between these, or move between the two for different patches)
generally, i think there are a lot more of the former AND even if they are the latter, tend to want to at least see/hear a patch, till they decide if they want to modify it.
so whilst indeed its not much effort to modify patches, i think the reality is, its a pretty small minority that go to this step 
but heres the problem…
as a patch developer, I don’t want to release (e.g.) Orac ‘tagged’ for PiSound when i know full well it can be used on any rPI… after all PiSound is ‘just’ an audio+midi interface (albeit a good one).
it makes no sense for me to ‘confuse’ other PI users, that somehow PiSound is some kind of requirement… when its not, any rPI will work.
so its a bit of a dilemma really
what does this mean? in the context of PD? what is specific to PiSound that is not true to any PI with a midi controller/audio interface?
the only specifics i know are, in/out gain which you have no control over , and a button … and with all due respect, one button is not worth coding for… you are still going to need a midi controller to do anything serious… and that is way more accessible than the pisound button 
1 Like
Yeah, the Pisound category makes sense given the ‘blokas.yml’ file containing patch metadata for use with the Pisound App, and will make even more sense after we release the next update. 
We’d love to see the community to converge to a common patching approach, and we hope the Pisound App and ORAC can help move towards that direction.
2 Likes
That’s a good point. Indeed I think that this probably applies to some extend to Pisound as well.
I’m certainly somebody in between. I know some Pd and got my hands dirty with linux in the past… but I’m certainly not an expert and do rely on other people’s help quite a lot. Which is another interesting point, but more about that later.
It’s also interesting to hear you point of view as a developer. I see this much more from my perspective as a final user of course.
The things specific to Pisound are (for now, as Giedrius points out) just in some intended uses, not something that is actually coded into the patch (well, except for the .yml file that is).
Things specific to Pisound would be:
- a certain, more or less standardize way to assign CCs and program changes (I think this is a point worth enforcing, since you don’t want everybody to use a different mapping scheme… Patrick’s patches do a good job at showing why it’s good to have a standard approach to CCs and program changes imho.
- 48Khz samples, if used
- only 1 stereo in and 1 stereo out
Admittedly it’s not a lot (when you compare to things like the Organelle), but maybe more is coming, so let’s see how this evolves! 
Getting back to the other topic, less experienced users. The more a platform like Pisound (and any other similar platform as a matter of fact) makes things both standardized and easy to customize the better it’s for everybody. Having some sane defaults and a basic standard approach helps both beginners to get into things, and reduces support requests for both the development team and expert users on the forums.
Things that fall into this category are to me:
- offering a pre-configured image that one can just burn onto an SD card (MODEP is a great example for that)
- having some standards in how Pd patches are created and distributed (which includes MIDI mappings) and how presets work
Adding a “pisound” tag would not exclude anybody from using a Pd patch made for Pisound on the Organelle, but it would inform you that you’d have to modify things in order to work. Same thing the other way around.
At the same time, I think it’s important that something like the Pisound ecosystem encourages modification and getting your hands dirty. It should also leave things wide open for the experts to do whatever they want. Finding a balance might be tricky, but it’s totally possible I think.
ok, not seen the yml file, as im not an android user
CC’s are more about controllers than PiSound , if i setup that controller using certain CC’s , it’ll work identically on pisound, mac etc.
this is a problem, which Ive solved with Orac by using midi learn… its the only real solution I think, given pisound users will have different controllers.
1 in/out is pretty common on most platforms - and an assumption most PD patches make
48khz samples, yeah thats a pain, but one (of a few) good reason why samples should be shipped/supplied separate from the patch.
my issue with some of this, is one im facing now with Orac,
(which as of today, Ive got running on 3 platforms , or 4 if you include macOS for dev. )
as a developer, I don’t really want to deal with PiSound separately, I think its a great product, but its a very small percentage of rPI users, so even though its what I use, I do not see why Id want to lock out other PI users.
so the problems mentioned need to be solved for all pi users, not just pisound users.
(this is why Ive built a mobile UI that is separate from PiSound’s, I need something everyone can use )
this is different from Organelle/Bela where the product is different, so to use, you have to do extra dev/steps.
anyway… its just my opinion,
I will be posting Orac and its mobile client as a rPI solution (rather than pisound) , but this does not stop other developers doing things more specific to pisound if they wish.
that is totally true indeed!
In the case of Orac that totally makes sense. Indeed Pisound is just an audio/midi interface from that point of view and Pd patches would need to work with Orac more than with Pisound and it would be silly to require you to release that specifically for Pisound.
As far as I can tell there’s not much that needs to be done to make Orac more Pisound specific anyway.
Actually I think the main misunderstanding point here might be that when I say “Pisound” I actually mean the Pisound App, not the hardware. The hardware doesn’t have anything really specific (except for the sampling rate, which is uncommon and possibly the number of outputs, which admittedly doesn’t make it very special as you said). What could require patches to be tailored to a specific use might be the app.
For now the app relies on a provided YAML file, which is not mandatory (if you don’t have it, you just name the main Pd file main.pd and that’s it) and on a more or less standardized MIDI setup, since there’s no midi learn. But as we have learned, that might all change, so there’s little point in discussing this I guess . The Pisound app creates a little ecosystem just like the Organelle or Bela does.
But it’s the same for Orac. Modules need to be made in a way so they work with it, so I think it’s not like you need an “Orac Pisound” category, but Patchstorage might need both an “Orac” and a “Pisound” category, or tag, or whatever.
1 Like
ah, fair enough… yeah, then i can see what you mean.
as i said, Ive no experience with the PiSound app, and won’t unless it turns up on iOS
yeah,Orac is a bit different, I guess, its kind of its own ‘PD ecosystem’… even on the Organelle, I just run it, then dont see the rest of the Organelle system again till I shutdown.
(though I admit thats just because at the moment Im SO focused on Orac )
1 Like
That was my impression as well! As far as I can tell Orac modules should run* on any instance of Orac no matter the underlying platform… or am I wrong?
(*) Except of course, for possible binary externals I guess, which would always have to be compiled for the proper processor architecture.
yes the externals would need compiling, but the core of orac I have running on organelle, pi, bela (so BBB) and macOS - the part that is platform specific (e.g. driving the organelle display) is now part of the ‘rack initialisation’, so that doesn’t create issues.
similarly the modules should be written in such a way that are cross-platform , except needing compiled binaries…
and as discussed sample rate for wav files,
or if the module/external has been written to assume sample rate, that might cause minor issues.
Just because I’m curious: any reason to do that, that can’t be solved dynamically via a [samplerate~] object?
an external will not use an pd object, but it does have the SR available from the pd lib. generally, coders/patchers should take SR into consideration, but there might be some cases (e.g. porting code from a hardware device) where it might be tricky, or of course it could just be dodgy coding 
I see, thanks for the explanation!