2010/10/11 Oleg Ivanenko <oivanenko(a)gmail.com>om>: Works just fine on Ubuntu 10.04 Your tools as always like katana -- lightweight, visually simple, and precise. -- Truly yours, Oleg Ivanenko aka Ash [if it wasn't so sad, it would be funny]

On Sun, Oct 10, 2010 at 05:27:25PM -0400, Jeremy wrote: The basic method for pitch detection is the same as in Autotalent. Some refinements are added: interpolation of autocorrelation peaks (improves accuracy a lot, in particular at higher pitches), some logic in the determination of the current note, and whatever it takes to make things work correctly at all sample rates between 44.1 and 192 kHz. The resampling is completely different - I never managed to grok how Autotalent does it. But whatever it does has some problems, just look at the spectrum of a 1 kHz tone 'retuned' to 987.7 Hz. Resampling is done by linear interpolation, at 44.1 and 48 kHz this is done on the signal upsampled to twice the original rate. It would be relatively easy to improve this further, but I don't think it would matter much. You'll find some comments on the algorithm used in retuner.cc. The computation of the required correction could be improved a lot by making the algorithm look ahead a few seconds. Of course this would mean off-line processing, e.g. operating on an Ardour region. Another improvement would be formant estimation and correction, for an off-line algorithm that would be relatively easy. Ciao, -- FA There are three of them, and Alleline.

On Mon, Oct 11, 2010 at 02:33:31AM +0400, alex stone wrote: I'm happy to hear you like it ! Not for the Jack apps. Rev1 and At1 are two of a collection of processors that will eventually be released as plugins in a 'rack' type of host. The GUIs and some of the internals are already designed to fit into that format. When that happens, the rack will have 'total recall' (session and snapshots), and each plugin type will have presets (per user). What I could do in the meantime is to provide them as Python classes (still with the GUI), which would allow them to be scripted easily. Mmm. Using 8 reverbs for a single orchestral mix doesn't make any sense - unless you are doing something psychedelic (*) they all play in the same space. It's easy to share a reverb for any number of channels even if the dry/wet ratio is different for each. (*) Like some opera CDs from DG wich have completely different reverbs for the orchestra and the singers - makes me seasick :-) Ciao, -- FA There are three of them, and Alleline.

On Sun, Oct 10, 2010 at 07:31:08PM -0400, Jeremy wrote: Yes, this will be a new plugin API, support libraries for both plugins and hosts will be provided, but I'm not going to actively promote it as a replacement for anything existing. It's not designed to be 'simple' - plugins and hosts *must* support a minimal functionality much wider than LADSPA or LV2. For example plugins must have a dedicated GUI, there is no such thing as a host constructing a GUI from e.g. control port descriptors - these are not even visible to a host. If a plugin supports multichannel use, this must be provided explicitly - the host can not just replicate the DSP code. There are many other differences, and some of them have far reaching consequences. This may well discourage 'novice' programmers, but that is to some extent intentional. I want this format to be used only for plugins that conform to some minimal quality standards. So it's not meant to provide an easy way to create a wrapper around some DSP code you don't even have to understand. I'm creating apps such as REV1, AT1 and some others as test cases. The specs are being reviewed and modified regularly as a result. Ciao, -- FA There are three of them, and Alleline.

On Mon, Oct 11, 2010 at 03:31:58AM +0400, alex stone wrote: None of this means you need to use more than one reverb, and if the target is to have more consistency you definitely should use just one. Reverb is a linear operation. If F1, F2, F3 are linear operations (EQ, delay, gain), then F1 (reverb (x1)) + F2 (reverb (x2)) + F3 (reverb (x3)) is the same as reverb (F1 (x1) + F2 (x2) + F3 (x3)) which uses just one reverb. * Set the reverb to 100% 'wet' and connect the outputs to your main mixing bus. * Send controlled amounts of each channel/group/section (after fader) to the reverb input. You can even equalise or delay these separately. Ciao, -- FA There are three of them, and Alleline.

On Mon, Oct 11, 2010 at 01:13:25AM +0200, fons(a)kokkinizita.net wrote: pretty adhoque jack session support for zita-rev1 is in this git: git://hochstrom.endofinternet.org/zita-rev1.git -- torben Hohn

On Tuesday 12 October 2010 15:52:19 fons(a)kokkinizita.net wrote: Does the software world need a better way to handle this reputation issue? (The rest of the world in general as well perhaps?) Is there any way to build a signed binary where this can be checked from within the binary itself? Perhaps stick the signature at the end of the binary and have the signing routine check all but the area that holds the signature? (Not well thought out, just an off the cuff idea.) all the best, drew

On Tue, Oct 12, 2010 at 5:11 PM, <fons(a)kokkinizita.net> wrote: Is releasing changes to other peoples' software really the equivalent of "the Far West"? Isn't that the entire point of releasing something under the GPL instead of, say, a shared source license? If you don't like the work he did, by all means, disassociate yourself from it, but please, don't say that you're not going to release any more software just because someone released a change to a GPL program of yours. Jeremy

On Wednesday 13 October 2010 03:16:08 Robin Gareus wrote: I am not a lawyer but as far as I know the only legally binding place to list authors of the code is the actual code-file itself. Thats why all files have a copyright-header stating the authors and the license... Of course it would have been more polite to send the patches to Fons first and ask for his input and thereby hope for inclusion in the official releases. Have fun, Arnold

On Wed, Oct 13, 2010 at 08:39:35AM +0200, Arnold Krille wrote: AFAIK that is correct. Anyway the AUTHORS, COPYING, INSTALL and README were added yesterday. Which would not happen. I've made it clear enough in the past that I will not support the current Jack session management system. Of course Torben has the right to add it, and I more or less expected this to happen as he wants to promote this system wich is mostly his brainchild. For me it's open question if going against the intentions of an author will in the long term advance or degrade the open source ecosystem. I don't think it will help to maintain a creative developers community. But what really upsets me is a release that does not work correctly, that clearly has not been tested to any real degree, and worse, makes it look as if it was the original. I don not want to be associated with any system that promotes such low quality standards. Ciao, -- FA There are three of them, and Alleline.

On Wed, Oct 13, 2010 at 08:39:35AM +0200, Arnold Krille wrote: a git repo is in no way a release. the copyright entitles someone to copy the file without adhering to the gpl. everybody can copy it. with a 20 lines patch i dont see myself gaining any copyrights on this code. and if fons wanted to sell stuff containing my patch he might well do so. i dont care. i pushed up a git repo. after his statement that there wont be session support i didnt think this was useful. anyways. switched git master to fonss original code. so someone unable to use git wont get my code. i am assuming that somebody who knows how to use git, is able to look who did the patches. -- torben Hohn

On Wed, Oct 13, 2010 at 02:03:22PM +0200, fons(a)kokkinizita.net wrote: fixed in 962001827a1b8f9dcc5f34a920964139fc79cb8a fixed in 7b6de5241acf3d7f8345178a4b989870c7ae8171 -- torben Hohn

What is "the Far West?" Do you guys mean "The Wild West" or something? -gabriel

On Wed, Oct 13, 2010 at 5:31 PM, Robin Gareus <robin(a)gareus.org> wrote: I think the colours are quite elegant. Cheerful without being aggressive. And Fons has, most importantly, refrained from using Godzilla Green, that terribly saturated affront to eyesight, and good taste, that some seem to find necessary in other apps to attempt some semblance of affinity with hardware equivalents. :) Alex. -- www.openoctave.org midi-subscribe(a)openoctave.org development-subscribe(a)openoctave.org

On Wed, Oct 13, 2010 at 04:30:34PM +0200, Robin Gareus wrote: The problem with this is that e.g. a frequency control on a parametric EQ is quite fundamental, while the one controlling the crossover between two reverb times is much less. Linear/log is irrelevant to the user. What matters is that the scale feels natural, that some essential values are marked and exact, and that the steps make sense. For AT1 and REV1 almost all controls are either lin or log, but other modules have quite special control laws on some of the knobs, e.g. the compression ratio on DC1. Even something simple like a Aux Send gain needs an ad-hoc control law in order to 'feel right'. It's usually quite clear if you have some experience with live mixing. Aesthetics are important, as is local consistency. 'Global' consistency is another matter. For example, different modules _should_ look differentl even if the layout could be the same, this makes it much easier to locate them in a rack. There's nothing as boring and confusing as a cartesian grid of rotaty controls that actually belong to different modules. As this is all 0.1.*, nothing is fixed ATM, and since the layouts are generated rather than made with some wysiwyg tool they will be easy to change and coordinate when the time comes. Ciao, -- FA There are three of them, and Alleline.

On Wed, Oct 13, 2010 at 7:36 PM, <fons(a)kokkinizita.net> wrote: Correct. And as a user, it might be fair to say i spend, and have spent, more time looking at apps for prolonged periods than most devs. Saturated colours might seem a good idea at the time, but in my humble experience, it's a sure fire recipe for headaches, feelings of ill intent, bleeding eyes, the urge to decapitate something, monitor destruction, etc, when used for any length of time on a regular basis. So we're agreed then. Godzilla Green, Murderous Red, Roaring Yellow, and oversaturated colours in general, shall henceforth be banned from the apps in our small but enthusiastic community, in a rebellious diversion from the......'norm'. Some revolutions are useful......... :) -- www.openoctave.org midi-subscribe(a)openoctave.org development-subscribe(a)openoctave.org

On Wed, Oct 13, 2010 at 8:20 PM, <fons(a)kokkinizita.net> wrote: I think you've got it about right for the rev1 background. It's neutral, and doesn't "draw the eye" away from the controls. Dark themes generally, imho, suffer from the same thing. In order to make the controls, or other visual components, stand out on a dark theme, devs seem to favour the complete opposite, with garish colours, each one competing with the next for the user's "eye". In other words, very little middle ground. The light theme in Ardour doesn't work for me at all, as it's all of the same thing, lighter upon lighter. My benchmark is eye strain, and headaches. The Ardour light theme gave me both after extended use. (And i hasten to say, this is not restricted to Ardour. ) I'm cautious by experience with recommending a particular app as an example, but there are some that definitely don't fit the bill for extended use, imho. Sawstudio, Ableton live, early Sequoia and Samplitude all fail in my view as they're built on extremes, with garish colours, or conversely all nearly the same colour in sections inhibiting any intent of relaxed use. I've never liked Logic's "mission brown" background, but it doesn't induce eyestrain or headaches for me with extended use, to be fair. Cubase and nuendo are fairly neutral, but have had versions that swayed from one extreme to another. Like using every instrument in an orchestra at once, it only takes a short time for the ear to dull, and for unique sound colours to disappear in to the wall of "grey". I think the same thing applies to visual design, and elegant restraint serves for a better foundation. I would say that from a power user perspective, neutral to mildly dark backgrounds are most conducive to extended use, and both elegant and restrained use of colour seems to be the most pleasant user experience. Anything stronger in intensity, or saturation, wears the eyes out pretty quickly. I'd also say that if a dev finds himself having to intensify the colour of a knob or button to make it "stand out", then something's wrong with the base colour in the first place. My views are my own, of course, and others will disagree on what constitutes a good appearance use case for them. -- www.openoctave.org midi-subscribe(a)openoctave.org development-subscribe(a)openoctave.org

Hi, On Wednesday 13 October 2010 18:56:27 Folderol wrote: When several windows are open, conformity is the key to usability. Things get much worse when every app uses its own colors and one editor is white on black, the next is green on black, the third is blue and red waveforms on light-violett tracks on dark-gray windows. While browser, email and office are all in the standard selected by the user. Which could be black on white or white on black or yellow on blue(*). Or its red on black because its all running on an foh-machine in the dark (where light colors are generally offensive to the darkness-adaption of the eye), unless you don't want your audio apps used under these 'special' use-cases. (*) Yes, that sounds and looks strange. But only to use not-impaired people. Some will get an un-usable experience with your app if it doesn't follow the system-standard. Rant: Its quite funny that more and more application- and environment- developers both from free open-source and from closed source, paid business invest more and more time and money into getting the visuals and the overall experience right and usable. And at the same time the audio community (okay, audio, not visuals...) is using pixel-based widgets and each-app-its-own- color-scheme. In a field of application (aka use-cases) where its important to quickly see the important parts without adjusting to different colors on every program-change. @Fons, this is not about your apps specifically. Its about the general direction of color-scheme development I see with many apps from many audio developers. We argue about rotation-vs-sliding on our knobs, can neither find a consensus nor a global way of settings so users can choose their behaviour. And we fail miserable by in anything concerned with usability (proven by studies of usability-experts! [*]) and claim its for better usability (but only in the eye of the programmer). This kind of sucks. Being told that my desktop sucks in usability because each app uses the same color-scheme is just a joke. I use that desktop every day and its much more confusing when I have to work with the very few (gladly!) apps that have different colors... Have fun, Arnold [*] No, I don't have references at hand. I just look at the big projects with their usability experts and their guide-lines. Which they create so that developers like you and me don't have to worry about colors, knob-behavior, widget movement and key shortcuts...

On Wednesday 13 October 2010 22:21:04 you wrote: That is not very fair to the usability experts working in universities, doing usability-studies on free software and for free software. Yes, they try to sell something. Free software for example... Ok, so my suggestion of using CTRL+Q for 'quit' is bad. Probably my suggestion for using 'whatever the user wants as shortcut for quit' is also bad. And using the colors the user wants (or needs!) instead of inforcing ones own ideas is also bad. I agree on the typical slider. The typical rotary knobs are bad too. But that doesn't really mean that every app should use its own invention with own graphics and own use-method, does it? Have fun, Arnold

On Thu, Oct 14, 2010 at 3:45 AM, <fons(a)kokkinizita.net> wrote: There is a solution for this, but it's outside the regular box. Split the app into zones. (navigate to a zone then have a generic set of shortcuts for the component in that zone) Mixer strips are an ideal candidate for this, as they usually present as the same per strip. (So each strip is a zone, containing shortcuts for each of the elements in that zone/strip) The problem is, as always, navigating to that strip in the first place, and that's usually the missing link in smooth navigation, unless of course you use the........mouse. Contrary to the perception that reaching the place you want to be is as "fast as possible", this is a big gap in most apps, and i'd suggest a careful review of linux audio apps will reveal that this "common" function is missing in most. I'd also respectfully suggest that directly translating hardware based functions to software isn't always the end of the story, and that additional thought needs to be given when setting up a shortcut based workflow in software for user flow that isn't present in hardware use, with navigation being at the top of the list. And a simple example of this is trying to get around any app without using the mouse. When you add up the number of navigation based actions a user will get through in a reasonable session, it makes sense to consider smarter, maybe software unique workflow design. You may be right for most audio functions Fons, but i would argue that only using a mouse for some basic navigation actions is not exactly hardware based workflow based. Changing the values for continuous controllers is relatively easy to do with the qwerty arrow set, provided those actions are coded, and the means to navigate to them is present in the first place. Using hundred of midi tracks constitutes thousands of controls with multiple CC controllers per track, and many apps get most of this fairly right, by using the method described above for zones. (poor navigation and poor multiple track management not withstanding) Having the choice to use or not use shortcuts is the most ideal of choices. Good point, but again, only once choice of user interaction (mouse), not only directly, but in a chain of actions the user might use constituting a wider workflow set. (I call them "klunk" moments, when the user has to abandon the qwerty to use the mouse, then back again. Not conducive to speedy use.) I'm looking forward to seeing your colour coded intuitive process, but i still don't understand why the idea of qwerty options for as much as possible is argued so enthusiastically against for workflow. Is it harder to code? Will someone come hunting me with a pitchfork and a torch if i, as a user, decide to use the keyboard instead? :) Alex. -- www.openoctave.org midi-subscribe(a)openoctave.org development-subscribe(a)openoctave.org

Excerpts from Arnold Krille's message of 2010-10-13 19:52:29 +0200: In my opinion the whole color business is completely overrated. I personally hardly give a crap about how consistent or inconsistent colors are, there are lots of more important things. I do agree that consistency can have its benefits. I had to do a lot of end user support recently, mostly on windows machines. It helped that the menus of at least each windows version where consistent, no matter whether the system language was Korean, Slovakian, Spanish or English. If something is the second menu item from the bottom it's the same in any language, when it's the icon with the cable, it's the same in any language. This is useful consistency. Also a lot more important than colors are shortcuts. 'Desktop guys', those people who dictate what a desktop should look like and how it should work, seem to be mostly 'mousers' who care about shiny icons and wallpapers to show off their cool desktops to windows users. Shortcuts are IMHO where the real usability improvements can be made. A simple practical example: I want to close a program. Simple enough, right? Wrong. Just from the programs I often use I know the following shortcuts: 1) CTRL+q 2) CTRL+w 3) CTRL+x 4) some shortcut to open a menu and another arcane one (never manage to figure those out) to select the quit option 5) indicated shortcuts (underlined letters) that don't work 6) no shortcuts at all The option to quit a program is probably the one thing almost all programs share, yet there's no consistency at all and I have to try on average three different shortcuts to get the desired result (or use my window managers shortcut..). That's really ridiculous. If you care about colors when there's a mess like this around I think somethings wrong.

Hi, On Wednesday 13 October 2010 22:58:52 Philipp Überbacher wrote: Yes, tell that to the visually impaired users of your software... For some of them, the ability to change the color-scheme (or even better just using the system-wide scheme) is _vital_. Or at least the only why to use your beloved apps. The same goes for fonts (type-face and sizes) and if you can use icons from the systems default, it will help users find the actions in the menus too. This probably applies to gnome only... KDE is very much keyboard usable and if the default shortcuts (with system- wide presets) don't fit your style, you can change them both system-wide and application wide. Did I mention that you can have two shortcuts at the same time for each action? Both are valid. CTRL+q shuts down the app, CTRL+w closes the window (like ALT+F4 does). Sometimes both result in the same, sometimes not (depending if the app can be running as a systray-icon. One more example: There are several 'common' ways to search: '/', CTRL+F and F3. Now guess how many of these chromium provides. And web-browsing is one of the most mouse- centric things! (For a laugh: chromium is the only app I use daily that is _not_ reacting to CTRL+Q to quit the app, you have to use CTRL+Shift+Q...) Here is the interesting thing: Using the big, bad (really?) toolkits, you get that consistency for free. Its only the small 'we know better then all others' who struggle with this... Which is why I am advocating the use of the more widely adopted toolkits. I may sound offensive, which I don't intent. What I am trying to say is that adhering to standards will free your mind from thinking about these basic things. Which results in more time to think about the actual job your app does. Which should result in more and better apps. Have fun, Arnold

Excerpts from Arnold Krille's message of 2010-10-14 01:16:58 +0200: It seems seriously visually impaired people use CLI tools. Font sizes are a whole different topic from colors. I know neither well, but I constantly run into programs that are obviously designed for mouse usage. Alt+F4 is either a windows or DE thing. It seems ctrl+w and ctrl+q is rather common, but see my examples further down this reply. I've only come across F3 in htop, afaik. ctrl+f seems to be dominant in windows land and / in linux land. No idea, never used chromium, but the programs I use usually provide one shortcut per action. Why do you think so? I don't see any reason for this and know examples to the contrary, cli browsers, uzbl, luakit, firefox with vimperator, .. Not my observation, examples I have to deal with regularly: smplayer: mainstream mplayer frontend, qt4 and quits only on ctrl+x epdfview: quits only on ctrl+w and is a rather mainstream gtk2 program eclipse: quits only on ctrl+f followed by x, a mainstream java program Those use the biggest toolkits out there, and are totally inconsistent. I bet I sound a lot more offensive :) I basically agree with you, but I don't see those standards. All I see are big DEs each cooking their own soup. From my perspective they only make my life harder, because each of those thinks they're right and are thus maybe even a hindrance to a real standard. What annoys me most is that they see their own DE, maybe 'the other one' and completely ignore everyone else. Their 'standards', even if they make some sense, tend to completely ignore non-DE users. It seems to be a lock-in game. That's why I despise DEs so much. Regards, Philipp