I've written some small c/c++ programs for my own use that were alsa midi
based. I found a very low entry barrier to getting started writing console
apps with alsa midi. I'd like to work on something a little larger scale,
and include jack midi with a gui to configure options, but have no idea
where to start.
I'd ideally like to use a loolkit that provides skinable interfaces, and I'm
familiar with html/css layout, so something where I can build the gui from a
layout file would be nice. If it can handle threading issues for me (rt
worker and non rt gui) even better.
What choices do I have for tools to use, and what pro's/con's are attached
to them. From what i've read so far qt seems like it might be a good choice,
aside from the high entry barrier of learning how to do everything the qt
way.
I'm looking for information on any of the above.
Thanks
Nathanael
Hello. I have installed jackdbus to have working ladish. If I start jackdbus (by "jack_control start" or ladish), legacy jack applications works. But if starting call produced by libjack applications, dbus apps don't see server.
If server already started, it should be right for dbus to check first, wether server already runing via libjack and connect to them instead to try start own server to no end.
Otherwise (IMHO, should be even more simple), also possible for libjack client functions to work always through dbus.
The source of problem is PulseAudio, which I hoped to work only with JACK. I am trying to solve problem with startup script, which kills jackd and starts jackdbus before pulse restarts.
(apologies for cross-posting)
Dear Colleagues and FOSS enthusiasts,
A friendly reminder that we have a Linux Laptop Orchestra (L2Ork) workshop at the NYC Resistor scheduled for May 30th, 2010 as part of the ICMC2010 workshop sessions. Please note the change in time which is 10am-4pm (ET).
For additional information and registration info, please consult the website at:
http://icmc-workshop-l2ork.eventbrite.com/
I would greatly appreciate it if you would please disseminate this as far and as wide as possible. For more info on L2Ork and its software/hardware resources, please visit:
http://l2ork.music.vt.edu
Many thanks!
Best wishes,
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
ico(a)vt.edu
http://www.music.vt.edu/faculty/bukvic/
hi *!
i need to re-synchronize two recordings of the same event that for
technical reasons had to be done with unsynchronized clocks. i'm
assuming for the sake of sanity that both clocks were perfectly stable.
my approach is this: in ardour, align some unique feature (a click in
this case) at the very beginning of the recordings to within a few
samples. set a mark1. then, identify another unique feature close to the
end, set mark2 to its position in the reference clock file and mark3 in
the file that needs to be resampled. read the frame positions or the
markers from session.ardour.
sample rate ratio is then
(mark2 - mark1) / (mark3 - mark1).
i compute a value of precisely 1.00020678091, and i'm now looking for a
resampler that will do the right thing here.
unfortunately, both zita-resampler and libsamplerate seem to represent
the sample rate ratio internally as a fraction of two integers, which
means that in my case, it will be rounded to 44100/44107. this is not
acceptable for the usecase at hand, as the offset after 4 hours of
recording would be too large. due to the massive amount of data to be
processed, slicing the material into smaller chunks to reduce the error
is not an option.
is there a hard technical reason for the behaviour of the resamplers?
would it make sense for this bear of very little brain to dig into the
code and try to convince them to perform resampling at ratios with full
double precision, or is such an undertaking bound to fail?
thanks,
jörn
Hey guys!
ReZound to me seems like one of the best sound editors on Linux. Yet, it
appears to have been forgotten. Any hope its development and maintenance
will be resumed?
Louigi.
So much to tell, even more to do... then one could hardly shake, this
long overdue. Lousy rhymes and no miserly times. And there it is: a
bug-fix release, I'll mean to ease.
Oh crap! Let's get it through once and for all.
With huge compliments to all who got the nerve and report as many too
much idiosyncrasies (nee bugs). Don't, never look back. There's plenty
more ahead, no matter where you look, or hear, whether is up or down hill :)
Qtractor 0.4.6 (funky deviless) is here!
Release highlights:
- MIDI Editor draw mode (aka paint mode) (NEW)
- MIDI Swing-quantize (NEW)
- LV2 UI Instance & Data-access extension support (NEW)
- JACK Session support (EXPERIMENTAL) (NEW)
- LV2 Save/Restore extension support (NEW)
- MIDI Editor event list in-line editing (NEW)
- MIDI Clip time-stretching (FIX)
- MIDI Clip editor file salvage quietness (NEW)
- MIDI Control bus switching crash (FIX)
- MIDI Bank-selection backout (FIX)
- Initial widget geometry extents (FIX)
- Input-only bus playback crash (FIX)
- Bus connection persistence crash (FIX)
- Drag-and-drop cloning plugins (FIX)
- MIDI Editor floating-selection persistence (NEW)
- Audio inserts garbage signal (FIX)
A bit more or not so detailed change-log is found below.
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
- source tarball:
http://downloads.sourceforge.net/qtractor/qtractor-0.4.6.tar.gz
- source package (openSUSE 11.2):
http://downloads.sourceforge.net/qtractor/qtractor-0.4.6-4.rncbc.suse112.sr…
- binary packages (openSUSE 11.2):
http://downloads.sourceforge.net/qtractor/qtractor-0.4.6-4.rncbc.suse112.i5…http://downloads.sourceforge.net/qtractor/qtractor-0.4.6-4.rncbc.suse112.x8…
- binary packages (Ubuntu 10.04):
http://downloads.sourceforge.net/qtractor/qtractor_0.4.6-4.rncbc.ubuntu1004…http://downloads.sourceforge.net/qtractor/qtractor_0.4.6-4.rncbc.ubuntu1004…
- user manual (outrageously outdated):
http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf
Weblog (upstream support):
http://www.rncbc.org
License (no kiddin'):
Qtractor is free, open-source software, distributed under the terms of
the GNU General Public License (GPL) version 2 or later.
Change-log:
- Introducing a non-painting edit sub-mode on the MIDI clip editor's
piano-roll (see Edit/Select Mode/Edit Draw menu).
- The MIDI clip editor (aka piano-roll) is now a lot more quiet about
saving its own dirty content, delegating all salvage questions to main
session control.
- Don't show session restart message box when changing JACK transport
mode option anymore.
- Dedicated MIDI control bus switching fixed. Was closing the wrong bus
eventually and crashing the whole show with it (fixes bug #2989590).
- MIDI bank/program backout has been corrected on MIDI track properties
dialog rejection (ie. user cancellation).
- MIDI bank select method has been corrected for tracks with no
instrument defined (probably fixing bug #2987071).
- LV2 UI Instance and Data Access extension support added; reduce LV2
external UI parameter value update flickering.
- JACK session infrastructure support. (EXPERIMENTAL)
- Initial widget geometry and visibility persistence logic has been
slightly revised as much to avoid crash failures due to wrong main
widget hidden state.
- Initial mixer widget extents are now set reasonably larger.
- General source tree layout and build configuration change.
- Ever since smooth-ramping introduction that having at least one
input-only buses were causing immediate playback crashes, now hopefully
fixed.
- Refactored for common engine client nomenclature, primarily provided
by JACK, then secondarily passed to ALSA Sequencer, getting rid of the
JackUseExactName requirement and lifting the unique/single instance
restriction in the process.
- Current JACK Transport, MMC Device, and MIDI Song Position pointer
(SPP) control modes are now saved/loaded as part of session option
properties.
- MIDI clip editor's context menu crash on Qt >= 4.6 has been fixed
(resolving bug #2972603).
- An ancient double-free corruption has been finally fixed at the
audio/MIDI bus connection persistence logic.
- Improved visibility of track state buttons text (R, M, S) when turned
on dark colored themes.
- LV2 Save/Restore extension support kicks off.
- MIDI engine read-ahead period has been shortened to half than it was
since inception--now it's a 500msec cycle.
- MIDI clip editor event list gets its due inline editing, for time,
note, value/velocity and duration columns, just one double-click away
over the target cell ;)
- Add-plugin selection dialog position and extent are now remembered
across invocations and application sessions (tipping by Frank Neumann).
- MIDI clip time-stretching is now made available through the same
gestures as audio ones, by just shift+dragging either of the clip edges.
- Drag-and-copying plug-in instances (cloning) is now fixed with regard
to parameter value replication.
- MIDI clip editor snap-per-beat setting is now independent from main
multi-track view; File/Save As... dialog fixed; the current event
selection is now kept floating as long as it's possible after editing
command actions; finally, edit mode has been extended to free-hand event
drawing, chalking off (piano roll) draw mode from the TODO list.
- Swing-quantize has finally made its overdue debut as an additional
MIDI clip editor tool (see Tools/Quantize...).
- Almost since its inception, audio inserts were injecting garbage
random noise when not being activated, now fixed.
- Dedicated audio output ports for MIDI track plugins, now have their
connection persistence back in business due on session load.
Cheers && Enjoy (what else?)
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Fri, May 21, 2010 11:30, James Morris wrote:
> Just a quick update. I eventually settled on a 64bit 2D array, with each
> 64bit element in the array representing 64 spaces in the grid merely for
> tracking the state of space being used or unused. Turns out much faster
> this way. There will still be a list of blocks (or windows if it was a
> window manager) placed but this is an entirely separate issue. For example
> in the test code I keep track of the coordinates (returned by the
> algorithm) and dimensions of placed blocks in an array.
>
> code/demo here: http://jwm-art.net/boxyseq/freespace_grid.tar.bz2
not very portable: uses GCC builtins ctzl, and clzl, and probably other
stuff not so portable.
>
> video/demo here: http://jwm-art.net/art/freespace_grid.ogv
>
>
>
> running 'make' in the src, builds a demo/test program which produces
> similar output to the video - this is where the good old xterm wins - set
> font to 'tiny' and maximize vertically and widen it to atleast 128 chars
> and xterm displays fast enough it looks like an animation.
>
>
> I'm hoping this will work well enough for real-time placement, though the
> worst case scenario has changed from just being 255 windows placed, to
> something like.... placing a 1x1 block in a non-empty grid full of (any
> dimensioned window... it's difficult to work out the worst case here.
>
> james.
>
>
> On Fri, April 30, 2010 23:10, James Morris wrote:
>> Hello,
>>
>> I'm still trying to develop my boxy-sequencer idea. Basically, I've
>> tried
>> out a couple of algorithms for window-manager-like box placement within
>> a
>> grid and run into big problems.
>>
>> Because I need help/advice/ideas, I'm posting here as it has some
>> relevance, and I've also posted to
>>
>> http://stackoverflow.com/questions/2746590/fast-block-placement-algorithm-a…
>>
>> A quick run down of what's happened so far, the two algorithms:
>>
>> The first I directly based on Fluxbox's Row Smart placement algorithm.
>> Testing only the data structures, (and with gcc -O0) jack kicked out my
>> client after around 200 boxes were placed in a 128x128 grid. I then
>> counted how many times the algorithm looped through the entire list of
>> boxes and discovered (not in RT for this) that the 256th box placement
>> required around 14000 scans through the list of 255 previously placed
>> boxes (i've decided 256 boxes will be the worst-case-scenario).
>>
>> The second algorithm consists of a freebox data structure which
>> represents
>> a rectangular area of free unused space. It also forms a node in a
>> doubly
>> linked list, as well as four directional links to other freeboxes
>> touching
>> it (with a maximum of one freebox touching each side of a freebox)...
>> turns out rather complex to implement fully: 700+ loc for a partial
>> implementation of row-smart left-to-right top-to-bottom placement -
>> theres
>> also col-smart, r-to-l, b-to-t and all combinations.
>>
>> Through stackoverflow, I've come across spatial hashing.
>>
>> I wondered if anyone here uses this technique for the display of data
>> (would scrollable window views use such a thing?). worth it for a
>> 128x128
>> grid etc?
>>
>> I'm just after any general thoughts/insights you might have as to what
>> might or might not work. Anything worth pursuing.
>>
>> I'm afraid there's all sorts of little things to be considered so if you
>> do have something to suggest, please read the stackoverflow post first.
>>
>> Cheers for any help, if possible,
>> James.
>>
>>
>>
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
Just a quick update. I eventually settled on a 64bit 2D array, with each
64bit element in the array representing 64 spaces in the grid merely for
tracking the state of space being used or unused. Turns out much faster
this way. There will still be a list of blocks (or windows if it was a
window manager) placed but this is an entirely separate issue. For example
in the test code I keep track of the coordinates (returned by the
algorithm) and dimensions of placed blocks in an array.
code/demo here: http://jwm-art.net/boxyseq/freespace_grid.tar.bz2
video/demo here: http://jwm-art.net/art/freespace_grid.ogv
running 'make' in the src, builds a demo/test program which produces
similar output to the video - this is where the good old xterm wins - set
font to 'tiny' and maximize vertically and widen it to atleast 128 chars
and xterm displays fast enough it looks like an animation.
I'm hoping this will work well enough for real-time placement, though the
worst case scenario has changed from just being 255 windows placed, to
something like.... placing a 1x1 block in a non-empty grid full of (any
dimensioned window... it's difficult to work out the worst case here.
james.
On Fri, April 30, 2010 23:10, James Morris wrote:
> Hello,
>
> I'm still trying to develop my boxy-sequencer idea. Basically, I've tried
> out a couple of algorithms for window-manager-like box placement within a
> grid and run into big problems.
>
> Because I need help/advice/ideas, I'm posting here as it has some
> relevance, and I've also posted to
>
> http://stackoverflow.com/questions/2746590/fast-block-placement-algorithm-a…
>
> A quick run down of what's happened so far, the two algorithms:
>
> The first I directly based on Fluxbox's Row Smart placement algorithm.
> Testing only the data structures, (and with gcc -O0) jack kicked out my
> client after around 200 boxes were placed in a 128x128 grid. I then
> counted how many times the algorithm looped through the entire list of
> boxes and discovered (not in RT for this) that the 256th box placement
> required around 14000 scans through the list of 255 previously placed
> boxes (i've decided 256 boxes will be the worst-case-scenario).
>
> The second algorithm consists of a freebox data structure which represents
> a rectangular area of free unused space. It also forms a node in a doubly
> linked list, as well as four directional links to other freeboxes touching
> it (with a maximum of one freebox touching each side of a freebox)...
> turns out rather complex to implement fully: 700+ loc for a partial
> implementation of row-smart left-to-right top-to-bottom placement - theres
> also col-smart, r-to-l, b-to-t and all combinations.
>
> Through stackoverflow, I've come across spatial hashing.
>
> I wondered if anyone here uses this technique for the display of data
> (would scrollable window views use such a thing?). worth it for a 128x128
> grid etc?
>
> I'm just after any general thoughts/insights you might have as to what
> might or might not work. Anything worth pursuing.
>
> I'm afraid there's all sorts of little things to be considered so if you
> do have something to suggest, please read the stackoverflow post first.
>
> Cheers for any help, if possible,
> James.
>
>
>
On 05/20/2010 09:08 AM, Jörn Nettingsmeier-6 wrote:
> hi *!
>
> in the light of recent timer discussions (was it here or on
> jack-devel?), lwn.net has interesting coverage about the time stamp
> counter and its oddities in the recent weekly edition:
> http://lwn.net/SubscriberLink/388188/62e8027425e224f6/
> (free link, the rest of the issue will become available to
> non-subscribers in 14 days or so.)
>
> best,
>
> jörn
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@...
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
Thanks for the link!
Interesting read.
So this is the monster that's being used when you start jack with -c
cycle...
Greetings,
lieven
hi *!
in the light of recent timer discussions (was it here or on
jack-devel?), lwn.net has interesting coverage about the time stamp
counter and its oddities in the recent weekly edition:
http://lwn.net/SubscriberLink/388188/62e8027425e224f6/
(free link, the rest of the issue will become available to
non-subscribers in 14 days or so.)
best,
jörn