Re: [Bluemusic-users] Thoughts on upcoming changes
Brought to you by:
kunstmusik
From: Jan J. H. <jj...@so...> - 2012-01-07 08:58:11
|
Dear Steven, dear list, here is my feedback, kind of late, bur I wanted to take my time to think about that: Am 31.12.2011 um 01:37 schrieb Steven Yi: > Hi All, > > * BSB: Update the UI altogether to make it "slicker" > * Make option for Knobs without value display > * Make Panel Groups, Panel can have auto-layouts > * Panel Groups as a feature can lead to concept of "sub patches"; > this would merge in some ideas from the Effects system, so that > effects could be come reusable as sub-patches in BSB I do like a lot the modular approach of sub-patches with re-usable effects. > * Theme > * I've been looking at finally cleaning up the theme. There's lot > of inconsistencies and cleanup to do, and I'd like to modernize the UI > to be very slick. I'm currently doing some sketching out of the theme > now, but this is slow work for me (but in the works) Sounds nice - although I still do like the current theme and was not too upset about inconsistencies, if I even noticed at all. I rather would prefer a find/replace search feature in the orchestra windows and a comment-out/comment-in feature. Also - I do not know, if this would be possible, I do miss a possibility to display k-rate values over time. It would facilitate a lot my debugging. Maybe also some kind of oscilloscope - window would be possible to? Then one could see sound ;-). But I do agree that it might be worth to clean up code and UI first, before exploring more possibilities for blue. > * Mixer > * Channels become more generic: for every instrument that has a > blueMixerOut, create n- number of channels that is equal to max > channels in the chain. This allows unbalanced in/out for effects > (i.e. having 9 channels going to 2 channels for ambisonic decoding to > hrtf output). sounds exactly like what I do need! > With the existing mixer, this would allow having the bsb > instrument be mono out, have effects which are mono, then have a > default panning knob on the mixer. The panning knob would be optional > though for backwards compatibility. > * Creating Mixer2 system: a different UI for a mixer, would be more > signal flow based. This would handle the complexities of mixing a > little more visually rather than relying on the metaphors of a > hardware mixer system. I am very curios on that :-) > * Libraries > * I am planning a more generic model for storage of data. This > means there would be a Library panel that has a tree. Each of the top > nodes would be of a type, i.e. SoundObject, Audio File, Analysis File, > Tuning, etc. There would be three levels of data storage: > Application-wide, Project-wide, instance-based (i.e. with an > instrument). The UI would change to have Libraries be it's own > secondary side component that can be moved, and likely would have two > trees, top for application-wide, below for project-wide. The two > trees would allow easy moving between the two zones for storing data. Sounds great. > * I am still trying to figure out patch storage for BSB. I'd like > to have a means where patches for an instrument can be shared with > "like" instances of that instrument, such that you can save/load > patches from the instance of BSB, a project-wide store, or > application-wide store. However, because you can change individual > instances of BSB, I need to figure out a system for making these > patches work with each other. I have been leaning toward it being a > user setting for setting a set identifier, or perhaps generating a > UUID but having a user settable name for the store. Sometimes I use to copy a UI into the RAM and just paste it to a similar BSB instrument. This now looks like an enhancement of this practice. Maybe even a translator for widgets made in CsoundQT and read-in into blue would be possible? Or - if we could get the API-mode going for me, it would no longer be necessary to migrate between CsoundQT and blue, no translator would be necessary then at all for me...still it would be great to be able to exchange UIs from both Csound frontends > * Plugin Layers > * I have still not gotten around to this, but it is definitely still > in the works. This allows plugins to allow new types of layers. > Currently there is only soundLayers for soundObjects, but imagine > layers for Notation, Audiofiles, etc. I am not sure what you mean: Do you mean to reorganize the soundLayer structure internally so that different types of Objects can be more easily implemented?Anyway: A possibility to read in Audiofiles would be great. All the best, Jan Jacob |