In writing arpage, I find that qtractor and seq24 provide good BBT data.
Ardour was ok, but Hydrogen didn't do so well.
-- sent from mobile
On Jan 22, 2010 1:40 PM, "Olivier Guilyardi" <list(a)samalyse.com> wrote:
On 01/21/2010 03:28 PM, torbenh wrote: > On Thu, Jan 21, 2010 at 07:48:20AM
-0500, Paul Coccoli wrot...
I think that Harry's question was more about time as he rephrased it in his
2nd
post, than about event queuing, although this is of course linked.
But in regard to time, what about Beat-Bar-Tick which seems to be important
to him?
How many applications support (set or handle) the Beat-Bar-Tick related jack
transport position fields?
In general, how reliable are these fields?
--
Olivier
_______________________________________________ Linux-audio-dev mailing list
Linux-audio-dev@lists...
Hi,
I search for a free and open source sound/music lib to integrate sound and music in a game.
The game runs on Lin/Win32/OSX so it has to be crossplatform.
I know openAL, but this is too big and tons of people have problems with it.
Anything slimmer around?
Nils
-------- Original Message --------
Subject: Re: [LAD] Hydrogen and jackmidi
From: m.wolkstein(a)gmx.de <m.wolkstein(a)gmx.de>
To: Christopher Cherrett <ccherrett(a)openoctave.org>
Date: 01/17/10 07:01
> Am Sun, 17 Jan 2010 05:30:38 -0700
> schrieb Christopher Cherrett <ccherrett(a)openoctave.org>:
>
>
>>> hi all,
>>> i am one of two/three active hydrogen developers.
>>> if you want new features or support for newer and of course great linux-audio
>>> technologies. so IMO, please create WORKING patches and submit them to our
>>> dev-mailing-list. than we can check them in.
>>>
>>>
>> Are you saying you are not interested in seeing jack-midi make it into
>> hydrogen with your help?
>>
>>
> no, i am interested on all. also on jack midi.
> please don't misunderstand me. in moment jack midi is not my personal priority. what not mean that jack midi is bad ore what ever.
> i have a normal job, children and as most people, few spare time.
> after 2 years developing on h2 and create a lot of code i found out that many people in the whole world have good ideas and are very interested on everything.
> e.g.to write functions or make new technologies working. but after 2-3 weeks mostly they lost their intention and leave a unfinished working place. mostly break up other function and
> all is unusable. this is why i say -make working patches-. i personally like talking about something. but i like it more, if people make tings working what they talk about.
>
> in an open source community we need constructive work. and not destructive discussions
> about thinks which are not possible if nobody work on them.
>
> :)
> greetings wolke
>
>> Is it only developers that get a say by coding something?
>>
>> I code for open source and for a living, I see great value in the needs
>> of the users. It is the only thing that allows an application to grow to
>> a professional level.
>>
>> IMO
>>
>>
I find it very valuable to find out who users are and what they are
doing with the app. I ignore certain users. After all, who likes to
waste time on things that do not get used. So I understand.
Speaking of jack-midi. It is the oly thing that keeps my setup running.
When using alsa midi the slows down and speeds up very bad. I find the
timing in jack midi to be far superior for professional work. When I run
jack midi it would be synced with jack transport running alongside of
900+ midi and audio connections. things get nasty with alsa midi :)
--
Christopher Cherrett
ccherrett(a)openoctave.org
http://www.openoctave.org
A quick question. Is Hydrogen now a jackmidi app? I've been searching
the interlink, and did see some discussion about it, and i wondered if
this was an impending reality, or a false dawn. I've downloaded the
latest stable but no jackmidi present as yet.
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
What? No automation, yet?
Yes I failed the promise once again. So what? What would you expect from
this self-called über-procrastinator? As sure is one to say that this is
the Year of Linux Desktop (YOLD:), I'll give you the shivers and command
this one will be the year of Qtractor Automation. No kiddin' ;)
Meanwhile, this new dot-release brings you several niceties, a couple of
them have been waaay longer and dustier on the all-mighty-overdue TODO
list than automation is. Rejoice! or else...
Qtractor 0.4.4 (frisky demivierge) is in the wild!
Release highlights:
* LV2 plug-in support (NEW)
* MIDI event list view (NEW)
* Expedite audio/MIDI clip import (NEW)
* DSSI plug-in output control ports feedback/update (NEW)
* JACK transport, MMC, SPP control options (NEW)
* Self-bounce/recording (FIX)
* Audio/MIDI drift correction (FIX)
* Anti-glitch audio micro-fade-in/out ramp smoothing (FIX)
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
- source tarball:
http://downloads.sourceforge.net/qtractor/qtractor-0.4.4.tar.gz
- source package (openSUSE 11.2):
http://downloads.sourceforge.net/qtractor/qtractor-0.4.4-2.rncbc.suse112.sr…
- binary packages (openSUSE 11.2):
http://downloads.sourceforge.net/qtractor/qtractor-0.4.4-2.rncbc.suse112.i5…http://downloads.sourceforge.net/qtractor/qtractor-0.4.4-2.rncbc.suse112.x8…
- binary packages (Ubuntu 8.04 LTS; no LV2 support):
http://downloads.sourceforge.net/qtractor/qtractor_0.4.4-1.rncbc.ubuntu804_…http://downloads.sourceforge.net/qtractor/qtractor_0.4.4-1.rncbc.ubuntu804_…
- binary packages (Ubuntu 9.10):
http://downloads.sourceforge.net/qtractor/qtractor_0.4.4-1.rncbc.ubuntu910_…http://downloads.sourceforge.net/qtractor/qtractor_0.4.4-1.rncbc.ubuntu910_…
- user manual (ever still outdated):
http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf
Weblog (upstream support):
http://www.rncbc.org
License:
Qtractor is free, open-source software, distributed under the terms of
the GNU General Public License (GPL) version 2 or later.
Change-log:
- For all the DSSI plugins that have output control ports, a host
feedback/update process cycle is now being finally provided: all output
control ports are now marshaled to their respective GUI process, rather
often and when found open/visible.
- MIDI clip editor (aka piano-roll) snap-to-beat behavior on edit mode
is now kind of more like 'filling-in-the-blanks' (as Frank Neumann et
al. wishes ;)
- Fixed MIDI clip editor mistake when reverting to initial clip length,
before closing and discard changes (thanks to Frank Neumann, for
spotting this one).
- LADISH Level 1 support has been added: SIGUSR1 signal trap just makes
it a shortcut to File/Save.
- Avoid parameter value flickering, due to duplicate command invocation,
most evident when changing values massively on native Linux VSTi plugin
editor GUIs (thanks to a detailed report on this odd behavior, from Mike
of linuxDSP.co.uk).
- Another TODO item bites the dust: MIDI event list editor, now
accessible from the MIDI clip editor menu (View/Events)
- Last used session directory is now made current on startup only when
no filename is given on the command line (solving bug #2920244).
- Current snap-to-beat setting (time quantization) now affects the
anchor event only, while dragging, moving and/or pasting multiple events
over the MIDI clip editor (aka piano-roll).
- Make anti-glitch audio clip micro fade-in/outs independent from
current buffer size as much as possible.
- Audio/MIDI engine drift correction gets really sophisticated, with the
help of (now old) ALSA MIDI tempo skew facility.
- Edit/Clip/Import... menu option is now available for expedite clip
insertion from audio and MIDI file requesters.
- Set default session directory effective to file's location.
- Audio track/clip recording process has been target to special
re-factorization across the internal audio engine process cycle, in a
late attempt to get self-bounce/recording effective and working
consistently for all track layouts.
- All session related dialogs are now set to window modality, (were set
to default application modality before) allowing for continued input
focus and interaction on all plugin/tool windows.
- An off-by-one nasty old bug fixed in audio clip drawing, was causing
instant crashes on certain zoom levels of the main track view.
- Graphical MIDI clip representation regarding note/pitch range is now
kept as much as possible across clip edits (cut, copy, paste, drag,
move, delete, etc.)
- LV2 plug-in hosting has finally come into actual implementation; only
some and the most basic LV2 plug-in features are supported at the
moment; probably there's no big advantage against the old LADSPA ones;
there's some support for external UIs though; also, LV2 MIDI/Event
bare-bones support is included but chances are it won't build nor work
right on most of the setups out there. It's a WIP host implementation
anyways, as is the whole LV2 spec. for that matter ;)
- Connections filter is now reset when widget is shown through the
View/Connections main menu or toolbar button.
- Audio bus auto-connection option is now applied when creating or
updating, newer or existing buses, respectively.
- Global configuration state is now explicitly saved/committed to disk
whenever View/Options... dialog changes are applied or when a session is
loaded or saved.
- Audio ramping spin-locking makes its smooth stuff, in an attempt to
reduce glitching and crackling when editing (due to its own pseudo
spin-locking) and toggling playback states.
- JACK Transport, MMC Device, and MIDI Song Position pointer (SPP)
control modes are now made optional (View/Options...), allowing for
discretionary configuration: None/Disabled, Slave/Input, Master/Output
or Full/Duplex (default).
- Session files may now be dragged and dropped over the main track view
and get loaded for business as usual (once quietly ignored).
- In an attempt to mitigate potential stack corruption and sudden
crashes, old commented out session pseudo-locks are now back in business
while executing clip editing commands (cut, paste, drag, move, insert,
delete) and playback is currently rolling.
- Adjusted first-time application window size to fit into 800x600 screen
size and with reasonable initial dock-ables layout.
- Avoid duplicate snap-to-grid effect when changing the length of MIDI
clip editor events across non-zero clip offsets (after a glitch reported
by Ralf Mardorf).
- Late audio track processing optimization, suppressing all plugin,
mixer and monitor pass-through activity when given track is muted,
either explicitly or implicitly (ie. other track is in solo state).
- Entering System Exclusive events (SysEx) on the MIDI clip editor (aka
matrix/piano-roll widget), yet something not fully supported anyway,
even though allowed in edit mode, doesn't crash the whole damn thing
anymore, while saving the clip to a file.
- Strict aliasing avoidance, with plain and demanded use of 'union', as
much as to stop nagging warnings from gcc >= 4.4.1 (last seen on
src/qtractorMidiEvent.h hackery).
- Visual correct play-head position while changing zoom levels,
applicable to both main track and MIDI clip editor views.
Cheers && Enjoy.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
dave phillips sez:
> alex stone sez:
> >This really surprises me. I would have thought you'd be inundated with
> >jackmidi requests.
> >
> >Another assumption on my part bites the dust.......
> >
>
> Add my droplet to the inundation.
>
> Vote++.
>
> Best,
>
> dp
I'd like in on this torrent of votes, as well! hydrogen jack-midi will be
SO GREAT!! I love hydrogen's interface; it is both intuitive and unique!
It will be very useful for controlling external hardware as well as other
software applications!!
thanks!!
~Maitland
Dear all,
Torben's new project brought back to my mind this mind-bending C++
template example (see attached), which I could not yet get to compile,
I have been told it has been compiled, but g++ will have none of it.
So I still have doubts on whether it includes legal C++ code or not.
But it is an interesting example (even if it does not build) of what
(possibly) can be done with templates.
My question to the list is: has anyone managed to compile this code?
Regards
Victor
Hello all,
The second development release of arpage is available on sourceforge in
source tarball and SVN formats:
Tarball: http://sourceforge.net/projects/arpage/
SVN: https://arpage.svn.sourceforge.net/svnroot/arpage/brancheshttps://arpage.svn.sourceforge.net/svnroot/arpage/tags
I'd like to thank everyone for the feedback I received on 0.1 - Please
check this out and let me know what you think, or if you have problems
building/running.
The UI is still dead-boring GTK, but I've read back over the LAD threads
regarding audio-oriented UI libraries and I'm thinking of investigating
libproaudio with the next release.
The 0.2 Development release adds:
- Smaller UI - probably not Netbook friendly yet, but getting closer :)
- UI should be dependent upon GTK+ 2.12 (rather than 2.16 as with the first
release).
- An additional executable named "zonage" which allows the MIDI note input
to be split into 4 ranges.
This is useful for routing sections of your MIDI keyboard to different
JACK inputs - e.g. route the lower half to arpage, and the upper half to a
"lead" sound, so you can "solo" over the arpeggiator.
- The ability to have a pulse duration (time between note-on and note-off)
be longer than the interval between pulses (time between note-on and
subsequent note-on).
This is useful when routing the output of one arpeggiator to the input of
the next arpeggiator. Experiment and hear it :)
- Noticeable decrease in the number of stuck notes (I haven't experienced
ANY with this version yet).
Basic features/requirements (same as 0.1 Alpha):
- svn / tarball only for now
- gtkmm-based, so dev packages for gtkmm and friends are needed to build
(and obviously jack)
- I've only built it on Ubuntu Studio (karmic) 64bit. I'm looking for
others to let me know if it builds/runs elsewhere.
- requires JACK time master to be rolling for the arpeggiators to do
anything. Qtractor and Seq24 have worked well for me.
- will pass midi events thru when JACK time master is not rolling.
- 4 arpeggiators with transpose, interval, range, note duration selectable
thru UI.
- Each arp has it's own JACK midi in and out port, so you can cascade
arpeggiators.
- Preliminary support for scales and modes - all of them are not correct,
but try major, dorian, diminished and augmented for starters :)
It sounds great with each arpeggiator driving an instance of calf mono.
Check out the ogg/mp3 clip on sourcefourge.
Thanks all,
Looking forward to any and all feedback.
Hi,
We are considering using PortAudio for Linux hardware support (and
Windows/Mac as well). What's the word on the quality, reliability,
ease-of-programming, latency and performance in Linux?
Our product (Receptor) is used in live situations by non-programmers, so
the support can't be "tweaky" if you know what I mean. The product only
needs to support a couple of sound cards, though, so it won't have to
target lots of hardware.
Thanks for any feedback,
Michael Ost
Muse Research, Inc.