the keyb/note object currently doesn't work here if i have it in a polyphonic subpatch set to 1 voice. It will be thrown off by other (than the selected ) note on/offs, thus rendering it useless.
I want to use it in monophonic subpatch mode but then i lose the device selection.
@thetechnobear suggested that its meant to have device selection?
the change is trivial... I've made it ...
BUT: @johannes this is is going to add a midi device selector (including omni) to all sub patchers,
theoretically this is correct, since it allows you to filter midi messages for mono patchers (as you can for poly ones) but are you ok, with having this on every patcher?
... the 'odd' side, is that its present on patchers that aren't using any midi objects.
(but trying to determine if a sub patcher is using midi objects is non-trivial I think)
I guess the other alternative, is we move the midi device filtering to the patch settings, but then its a bit hidden.
this would be more like the fixed midi channel setting rather than the midi attribute mode.
(but I have to say I actually prefer the midi attribute and devices on the patchers, i find the settings a bit hidden)
@chaosmoon , we should probably also look at keyb/note and why its not working in poly mode.
what is happening in poly with 1 voice? is it a bug or not just working as you expect?
(I assume this is related to the other topic on legato..)
Perhaps its visibility should depend on the HasMidiChannelSelector flag in the PatchSettings?
sounds like a good idea, perhaps rename it to just midi selector ... easy change to make.
I'll make the polys use the same.
this might break the 'odd' patch where user have filtered by midi device on the poly but I think thats not going to be many, and better to have consistency going forward, and also will make it a bit cleaner in the UI.
I'll finish the changes tommrow then push it.
@thetechnobear in poly mode it will filter the incoming note, but other note on/offs will interfere with the filtered note's on/off. You wont hear other notes getting through, but if another note is triggered near or at the same time as the target note it won't sound.
here's a patch to demonstrate. Choose your incoming device and send a pulse on note 48. Then add a lot of notes on 49 and you'll notice the problem.
keyb-note.axp (3.3 KB)
sorry, I dont really have time to look at this (poly count = 1 behaviour), perhaps log as a Github issue.
good news is Ive implemented and pushed to git the device selection for mono voices,
as suggested by @johannes these device filters are now accessed 'enabled' by selecting the 'has selector' on the patch settings, otherwise it defaults to all devices/ports... which is the 'usual' requirement for many.
( I cant promise this will do as you require of course, only that it will enable filtering on mono subpatches 
)
we are working on a few things at the moment for a new release, hopefully this release wont be too long, but its got a lot of changes, so please bare with us we need to be happy its stable etc.... we are considering a pre-release to help get things tested
pardon my ignorance but is there a walkthrough for compiling from Github? I've only ever compiled stuff by walkthrough.
i have XCode and am running OSX 10.8.5
Sorry not really... its not something Ive got around to documenting yet.
its not particularly difficult if you have development experience, essentially just clone from github then run build.sh in the platform_osx/windows/linux.
theoretically that should download, install everything it needs, and then build it.
be aware, at the moment we are doing something new which means there is an extra step required to initialise the submodules. its noted in the README file.
personally, Id refrain from this unless you have some development experience.
as I said, we plan to have a pre-release out soon (and may do this more frequently in the future to aid with broader testing etc)
ok thanks. I had a look at setting up Git but will wait for your build.
Is there a possibility to do something like the pure Data auto/nightly builds in the future?
we have discussed it.... its possible we could do this for mac/linux (using travis, travis does not support windows)
but it would still then be unsupported... and probably is more effort than its worth.... but never say never.
please bare in mind Johannes is the only 'employee' of axoloti , and I contribute as much as I can - so theres is only so much we can do, especially since its not just dev but support, hardware dev etc.
so things like this could actually be counterproductive... more support = less development time.
hopefully over time other developers will join the open source development, then we will get more things done.
also if other (non-developers) community members wanted to contribute, they could in documentation, or tutorial videos - all would help, and free up time for development.
