[LAD] [ANN] Qtractor 0.7.9 - A Snobbier Graviton release
So it's the last equinox'16... And the last of the Qstuff* End of Summer'16 release parties [7][8]. Qtractor 0.7.9 (snobbier graviton) is now released! Release highlights: * Audio/MIDI metronome anticipatory offset (NEW) * Current clip highlighting (NEW) * SFZ sample file archive/zip bundling (NEW) * MIDI transpose Reverse tool (NEW) * MIDI (N)RPN running status and NULL support (NEW) * MIDI Controllers catch-up algorithm (FIX) * MIDI track Instrument menu (FIX) * JACK shutdown and buffer-size changes (FIX) Qtractor [1] is an audio/MIDI multi-track sequencer application written in C++ with the Qt framework [2]. Target platform is Linux, where the Jack Audio Connection Kit (JACK [3]) for audio and the Advanced Linux Sound Architecture (ALSA [4]) for MIDI are the main infrastructures to evolve as a fairly-featured Linux desktop audio workstation GUI, specially dedicated to the personal home-studio. Website: http://qtractor.sourceforge.net Project page: http://sourceforge.net/projects/qtractor Downloads: http://sourceforge.net/projects/qtractor/files - source tarball: http://download.sf.net/qtractor/qtractor-0.7.9.tar.gz - source package: http://download.sf.net/qtractor/qtractor-0.7.9-27.rncbc.suse.src.rpm - binary packages: http://download.sf.net/qtractor/qtractor-0.7.9-27.rncbc.suse.i586.rpm http://download.sf.net/qtractor/qtractor-0.7.9-27.rncbc.suse.x86_84.rpm Git repos: http://git.code.sf.net/p/qtractor/code https://github.com/rncbc/qtractor.git https://gitlab.com/rncbc/qtractor.git https://bitbucket.org/rncbc/qtractor.git Wiki (help wanted!): http://sourceforge.net/p/qtractor/wiki/ License: Qtractor [1] is free, open-source Linux Audio [5] software, distributed under the terms of the GNU General Public License (GPL [6]) version 2 or later. And the boring complete change-log follows: - JACK buffer-size change handling has been deeply improved, now doing an immediate session restart, while preserving all external connections as much as possible. - Introducing an audio and MIDI metronome anticipatory offset, kind of latency compensation, to respective option settings cf. View/Options.../Audio, MIDI/Metronome/Offset (latency). - Fixed LADSPA plug-in preset switching, incidentally broken as NOP, ever since late Haziest Photon's crash-landed. - MIDI Track/Instrument cascading menus have been found empty broken on Qt5 builds, now fixed. - MIDI RPN/NRPN running status and RPN NULL reset command are now supported (input only). - Fixed a sure immediate crash on removing audio buses that are current targets of any active Aux-send inserts. - Fixed yet another old bummer that was reaping off assigned MIDI controllers on existing track's gain/volume or panning controls, when adding any single new track. - Fixed missing feedback on MIDI controllers assigned to any of monitor, record, mute and solo track/bus state buttons. - Eye-candy warning: the current clip, not necessarily the one currently selected, is now highlighted with a solid outline; linked MIDI clips are also highlighted with an alternate dashed outline. - SFZ file conversion, and bundling of the respective sample files, is now supported when saving as zip/archive (*.qtz). - Fixed track monitor, record, mute and solo dangling states, on Track/Duplicate command. - Slight regression on the LV2 State Files abstract/relative file-path mapping, trading QFileInfo::canonicalFilePath() for QFileInfo::absoluteFilePath(), and thus skipping all symlink dereferences in the process. - Fixed a one first linking/ref-counting glitch, affecting recently recorded MIDI clips which might have their initial clip length still un-quantized to MIDI resolution (BBT). - A brand new and discrete MIDI clip editor command tool has been added: MIDI Tools/Transpose/Reverse. - Discretely fixed MIDI Controllers catch-up algorithm. - Fixed a borderline mistake on plug-in parameter port index mapping to its corresponding symbolic name, especially if newer plug-in versions are loaded on older saved sessions. References: [1] Qtractor - An audio/MIDI multi-track sequencer http://qtractor.sourceforge.net [2] Qt framework, C++ class library and tools for cross-platform application and UI development http://qt.io/ [3] JACK Audio Connection Kit http://jackaudio.org [4] ALSA, Advanced Linux Sound Architecture http://www.alsa-project.org/ [5] Linux Audio consortium of libre software for audio-related work http://linuxaudio.org [6] GPL - GNU General Public License http://www.gnu.org/copyleft/gpl.html [7] The QStuff* End of Summer'16 Release http://www.rncbc.org/drupal/node/1696 [8] Vee One Suite 0.7.6 - The Eleventh beta release http://www.rncbc.org/drupal/node/1699 See also: http://www.rncbc.org/drupal/node/1700 Enjoy && Have (lots of) fun. -- rncbc aka Rui Nuno Capela
Re: [LAD] aBLETON lINK
On 09/21/2016 11:24 AM, Perry Nguyen wrote: > > Though after reading your post to LAD a couple times over it seems like > there is possibly overlooked but important incongruity between BPM and > "linear/real-time".. and perhaps that limits the ability of word-clock > time designators like JACK from seamlessly following BPM? If that is the > case it is still unclear to me what the specific technical details of > that incongruity are. > (continuing my own babbling...:)) read this? http://github.com/jackaudio/jackaudio.github.com/wiki/TransportLimitations (JACK Transport Limitations) ok. now from the top of my head. a. jack-transport/timebase (JT) is a centralized master/slave model, including its API approach; corollaries follows: all JT clients start and stop on demand and at the same time; netjack clients might drift apart, unless they implement some sort of PLL/DLL device (anyway, this assumes one of the participants is master); time reference is absolute frame position, constant sample-rate (frames/second), starting from a designated master application, linear (tape-like) timeline model (a song, session or project as a whole length continuous composition or arrangement). b. ableton-link (AL) is a distributed metronome facility and API; any AL client may or not be playing its thing on any given time, but when they play, they *should* start and sync (internally on their own premises) on beat boundaries on their own best-fit strategy model; time reference is tempo (BPM; beats/minute); tempo changes are broadcasted (well, dang truth is multicasted), may be initiated by any participant, then each other participant may react accordingly (or not) on their own chance, next cycle or phase, whichever fits best their own designed playback model--this is why, AL is more suited for loop-based contraptions that straight linear-tape model ones. you can map AL to JT (timebase) if you will, but it's one master's job to do it--make the time calculations according to its own master, static tempo-map. hth. cheers -- rncbc aka. Rui Nuno Capela ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] aBLETON lINK
On 09/21/2016 12:24 PM, Perry Nguyen wrote: > I am still vaguely under the impression that if a Timebase master client is > Link-capable then any transport-aware client (e.g. most LAU apps today) > would be able to follow any tempo changes described by the master and > therefore automatically have "Link support" Theoretically, yes. A jack timebase master is supposed to translate current absolute position to musical time. It's mainly useful for tempo-maps. Ableton Link does not provide an absolute reference, so the client would have to maintain an internal count depending on transport state, infer that information and keep track. Still jack-position is versatile enough to represent information provided by Link: http://jackaudio.org/files/docs/html/structjack__position__t.html The real question is if it's useful and how many jack-apps can cope with potentially non-linearity WRT to absolute jack transport sample time. ciao, robin ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] aBLETON lINK
hi, I've posted about Ableton Link a number of times now on LM and LAD but I was never satisfactorily responded to.. Here's my post from LM https://linuxmusicians.com/viewtopic.php?f=1=14913 here's the same thing I posed on LAD http://linux-audio.4202.n7.nabble.com/ableton-link-and-live-tempo-changing-td99835.html well I hope someone sees my post this time. But anyway I'm just copying my message from LM if anyone has opinions: Hey rui, I've noticed the discussions on github/LAD (the latter of which i am still unable to post on[image: :?] ) and your PR to Link. It seems like you've made reasonable progress with it-- can you comment on how feasible the ideas I described in my original post are? I am still vaguely under the impression that if a Timebase master client is Link-capable then any transport-aware client (e.g. most LAU apps today) would be able to follow any tempo changes described by the master and therefore automatically have "Link support"-- from my understanding the JACK Timebase includes transport control and BPM information (though maybe not beat sync information like Link?). Then can't a timebase master client be Link-obedient just in regards to BPM but operate transport independently (since Link doesn't have transport a transport representation anyway)? Though after reading your post to LAD a couple times over it seems like there is possibly overlooked but important incongruity between BPM and "linear/real-time".. and perhaps that limits the ability of word-clock time designators like JACK from seamlessly following BPM? If that is the case it is still unclear to me what the specific technical details of that incongruity are. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
