Comments by mwicat
@XerwinXpl yes, it's a feature ;] I tend to use it on separate "utility" track so it wasn't a problem for me. But if that makes it tricky to use I could add some checks...
Posted on October 18 2022 by mwicat |
Report Issue |
See Comment
@WHZLY the latter, device goes anywhere, like master track. Then you select the track (with mouse, keyboard or whatever), then you use your binding (for example the "n" key for keybinding since it seems to not conflict with anything). If there is more than one track selected at that moment, it will handle the last and create render track for it.
@vingtdeux fixed bugs. I believe floating "bpatcher" object is not really possible since only window created from "patcher" object is willing to obey window flags. I was curious how far I can hack around this though, so in the end I added "detach" toggle to open normal window from bpatcher and "float" toggle to open floating toolbox window (like Live plugins) from patcher. No free launch for you though.
Firstly, there are now two patchers - one in bpatcher and one in ordinary patcher coexisting. I'm not sure if this won't open a new can of worms, although I've taken some measures against it like activating monitoring from bpatcher deactivates monitoring in patcher to avoid having two PreviewFinders. :)
Secondly, floating window means that it will float on top of Live window but will disappear when focus goes to another process' window (like the Finder's one :D). This is the same issue that happens with every VST plugin in Live so I don't believe that it can be fixed. That is why I implemented both options to "detach" the device and to "float" it.
Firstly, there are now two patchers - one in bpatcher and one in ordinary patcher coexisting. I'm not sure if this won't open a new can of worms, although I've taken some measures against it like activating monitoring from bpatcher deactivates monitoring in patcher to avoid having two PreviewFinders. :)
Secondly, floating window means that it will float on top of Live window but will disappear when focus goes to another process' window (like the Finder's one :D). This is the same issue that happens with every VST plugin in Live so I don't believe that it can be fixed. That is why I implemented both options to "detach" the device and to "float" it.
@WHZLY well if somebody is willing to turn this code at https://devblogs.microsoft.com/oldnewthing/20040720-00/?p=38393 into external object that will output currently selected file on bang then why not :D I don't have Windows machine at the moment, let alone a programming environment for this task. Would be rather easy for somebody experienced with programming externals though, given that WINAPI solution is already provided.
Added option to float the patch in a new window. I couldn't find any working solution for true floating window that stays on the top of Live window so its usability is somehow limited. If anybody has working example of such feature, please share. @vingtdeux what do you mean by a "grab sample" feature?
@vingtdeux Yeah, I forgot to fix the output routing. :) I also thought about the other improvements that you suggested especially the playhead, just have to figure out how to implement it. What version of macOS do you have? Would be good to know it it works correctly on >= 10.15 Catalina systems.
BTW I tried to use dedicated sample management apps like Audiofinder but then I realised that my preferred workflow is to work with raw filesystem hierarchy, instead of managing dedicated library where every file is kind of "floating in the void" until I provide some filter terms. I guess that having files organised in the tree hierarchy provides better overall picture. IMO, the best combination would be to have filesystem hierarchy but with fast tag search. Finder has built-in preview but is kinda slow to work with, on the other hand the "column" view mode is really great for fast switching between different sample packs etc.
BTW I tried to use dedicated sample management apps like Audiofinder but then I realised that my preferred workflow is to work with raw filesystem hierarchy, instead of managing dedicated library where every file is kind of "floating in the void" until I provide some filter terms. I guess that having files organised in the tree hierarchy provides better overall picture. IMO, the best combination would be to have filesystem hierarchy but with fast tag search. Finder has built-in preview but is kinda slow to work with, on the other hand the "column" view mode is really great for fast switching between different sample packs etc.