Another stupid question induced by an argument regarding to MIDI jitter
by Daniel James.
> [snip] I'm sceptical that
> the realtime kernel is the cause of your MIDI problems. If they got this
> right in the 80's, on computers which could not do anything near
> realtime audio processing, then I think it's more likely to be a
> question of MIDI application design.
IMO it's a good hint.
Why do people (not only me) report jitter for external MIDI equipment,
but I couldn't find any report for real-time audio jitter? Resp. what's
about async and disconnecting clients by JACK? Does this regard to the
same issue, caused by the hardware combination?
And it's not only for Linux, but for e.g. Windows Cubase too, while
Cubase on the Atari is ok. OTOH on Windows audio clients don't
disconnect, just MIDI jitter is an issue too.
Cheers!
Ralf
Qjackctl has the -n option to select a Jack server name,
and recent versions also allow multiple presets.
What would it take to make the server name a element of
a preset rather than a command line option ?
That would finally allow to run multiple jacks on the
same machine (something I've been doing quite a lot
recently) without having to start each qjackctl with
a different command line option (e.g. from a desktop
menu).
And maybe the four start/stop scripts should also be
'per preset'.
While we're here: almost no apps support selecting a
specific Jack server. I've been adding this to some
of my own just because I needed it.
Using -n for this can be problematic if the toolset
used doesn't allow context-sensitive options: -n is
also used as a parameter for an ALSA interface, and
some apps support both Jack and ALSA.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
I thought very long, that it don't support JACK. But I just ran ldd, and saw a dependency on libjack.so.0. And if I try to playback when jackd is not runing, it says, that could not connect to jack server. If server is runing, it doesn't produce any signals, but silently prefers alsa. I have JACK2 and tried both with jackdbus and legacy jackd. So, what is situation?
I assume, it is undocumented and half-complete feature, but it is interesting, to have an expert opinion. I could not find any helpful information about.
> I am also interested in your gtkmm widgets..
> Could you send them to me also?
>
I decided to also post them to a github repo in the end.. (backups are
always good).
git clone https://harryhaaren@github.com/harryhaaren/Gtkmm-Custom-Widgets.git
should give you a folder called Gtkmm-Custom-Widgets in your ~/
Cheers, -Harry
PS: I have at least one more widget to add in there, and probably more from
various little
other projects I have here... will probably be done in the next few days.
(They'll need some
small changes to compile without OSC libraries etc..)
> > wait, isn't the
> > LV2UI_Descriptor->port_event() and LV2UI_Write_Function() interface
> toolkit
> > agnostic? Wouldn't it be possible to have toolkit agnostic host-
> facilitated communication?
>
> Yes, these are. And these allow plugins to communicate
> with other plugins.
>
> However, these functions are executed in the host
> application's memory space. So, I don't see how it would
> help in having FLTK widgets hosted by a Qt application.
Could a 'fake' (facade) LV2 host interface be supplied by the GUI process,
then forwarded somehow to the main application process? Like how VST Version
3 works?
Hi all,
I am thinking about making a custom GUI for the Autotalent LV2 Port, which
would allow the user to select scales easier and perhaps provide some eye
candy ;).
It seems that there is some issue with LV2 GUIs being not cross-platform
because they require GTK. Therefore it seems to make sense to create a GUI
using Qt, so it will work on most imaginable platforms. However, when I
started googling, I found a discussion on the topic by the author of the
Composite sampler, who wanted to do the same thing. It seemed like he was
actually writing a new extension in order for this to work. However, I
couldn't find any further work on that project, and currently the Composite
plugin doesn't have a custom GUI at all.
So my questions are:
Is it possible to create a Qt GUI with the currently designed extensions?
Which extension should I use if so?
Which hosts support which type of external GUI creation? Would it take
additional code to get any Qt GUI running under them?
Is there any reason I should not use an external Qt GUI?
Where should I start with getting an external Qt GUI to run?
Thanks,
Jeremy
I've been reading the LV2 docs for the N-th time, as well
as lots of examples, and it all remains complete completely
incomprehensible to my problably too primitive mind.
So I have a simple question:
What is the absolute minimum required to define an LV2
plugin (in other words, which files, and what do they
need to contain) assuming the following:
- The plugin requires one 'extension'.
- This extension defines everything except whatever is
required to enable a host to discover the existence
of the plugin on a system.
- In other words the extension defines how the host is
supposed to instantiate and call the plugin, the way
ports and parameter are described, etc. etc.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
>On Mon, June 14, 2010 7:40 am, Robin Gareus wrote:
>> On 06/14/2010 03:51 PM, Philipp wrote:
>> If a custom tracker should be developed at some point, then
>> it shouldn't happen behind LAD doors but together with other parties
who could benefit from it and likely have more expertise in that area.
>>
>> The closest existing thing I know is http://openhatch.org/, which pulls
all or some bugs from lots of trackers, but I'm not sure it's close to
what is needed here.
>
> AFAICT openhatch tackles a different problem: get people on a project. I
don't know if it can be useful for improving interoperability and
inter-project problems; but it could be a start.
>
It makes sense to me to integrate the functionality it provides as another
option. The trick is to figure out how to best integrate it...
>> My idea for the near future was to simply use an existing wiki,
possibly on linuxaudio.org (mainly because of the domain name). In the
simplest form I believe, tags could be used for applications (to find
all issues involving the specific app), pages for the issues and page
subscriptions for notification.
>
> Those features are all already present at wiki.linuxaudio.org.
>
> There's been some complaints about the current style; but no-one has
stepped forward and provided a better template yet. FWIW you can switch
the look&feel at http://wiki.linuxaudio.org/wiki/user/rgareus
> the "experimental" there is a contender for the new default. but it's
not yet XHTML clean and requires javascript.
>
> If one wants to pick up a project he/she can already find
> http://wiki.linuxaudio.org/apps/categories/unmaintained
> and
> http://wiki.linuxaudio.org/apps/categories/dead_link
>
It's true that you can find it but how many people actually do find it?
IMO brining this info out to the forefront should be a prerequisite for
the tracker page. In fact it would be useful to add these links to the
planet-bugs page so they have additional SEO for people coming to the site
from an engine.
>
> From the top-of-my head, here's how we could start:
>
> go to http://wiki.linuxaudio.org/wiki/bugs/ISSUE
>
> Where ISSUE eg: synchronization
> - create or edit the wiki-page
> - describe the problem
> - add links to affected software
> eg. [[apps:all:ardour]], [[apps:all:hydrogen]]
> - optionally add external links to upstream trackers.
> - optionally add {{rss>TRACKER-FEED-URL}} for issue upstream.
>
> The backlinks ("what links here") feature of the eg.
> http://wiki.linuxaudio.org/apps/all/hydrogen
> page will show related bugs. It will be easy to make a "show only
backlinks in the 'bug' namespace" feature.)
>
> Once we have a few test/example pages we can add wiki-shortcuts to ease
the workflow. There's also the possibility to have a small form that
will create a new wiki-page according to a template using
> http://www.dokuwiki.org/plugin:bureaucracy
>
I think this is a prerequisite for any form of wider adoption. Just
looking at the method described herein is enough to scare most people ;-)
I will be happy to assist with the form once we have defined and tested
the basic system if this turns out to be the preferred way to handling the
meta tracker.
> Then we'll "only" need to make developers of said application aware of
the bug-reports:
>
> This could happen using feeds:
> http://wiki.linuxaudio.org/feed.php?mode=list&ns=wiki:bugs:ISSUE
>
> or subscribing them to the "page change notification" of said issue.
>
Both options should be provided but the most likely to be useful will be
email notifications and automatically adding the bug to the applications
existing tracker.
> or it can be one of us, playing man-in-the-middle forwarding these bug
upstream.
>
Who's gonna pay for that persons time?
> A nice feature would be subscribe to 'pages with tag XXX'; that is not
yet possible; but I can whip up a plugin for that if once need it.
>
>> I'm no expert on wikis, so I'm not sure whether there
>> are more features that could be used to fulfill more of what we'd want.
>
> right; so far we have a problem description and brainstorm about
possible solutions but not actually a use-case list of "what we want".
>
I think it is being clarified now.
--
Patrick Shirkey
Boost Hardware Ltd.
--
Patrick Shirkey
Boost Hardware Ltd.
--- Begin forwarded message from Philipp Ãœberbacher ---
From: Philipp Ãœberbacher <hollunder(a)lavabit.com>
To: Robin Gareus <robin(a)gareus.org>
Date: Mon, 14 Jun 2010 13:31:40 +0200
Subject: Re: SPOOFED: Re: [LAD] meta issue tracker idea
Sorry, this message went to Robin only by accident.
Excerpts from Robin Gareus's message of 2010-06-13 14:14:13 +0200:
> The motivations are clear - you may have gotten some details wrong (eg
> Paul is working on quite a lot besides ardour) - but the tenor is right.
What I meant was that he never implemented anything that could have
solved the session management issue in ardour, be it lash, any of its
predecessors or anything more recent. I know that torben worked on a
jack_session patch for ardour, but as long as it's not in ardour it
doesn't help much. The reasons for this could be manifold and I won't
speculate at this point.
> The problem is: how to implement and maintain it? Just setting up a
> tracker is easy; getting people to use and listen to it is the first
> hurdle. Integrating it with upstream trackers the second.
>
> Do you know of a system up for the task that we can install without
> large development on our side?
>
> If you have a good idea or elegant prototype, we can hook you up to
> manage the tracker.linuxaudio.org vhost. None of the people involved in
> LAO [1] are currently available for such a task; well, maybe Patrick is?!
>
> Cheers!
> robin
>
> [1] http://lists.linuxaudio.org/pipermail/consortium/2010-April/002036.html
I think you're thinking more complicated than I did initially. Who says
a custom tracker, the possibility of integration with upstream trackers
and whatever other fancy stuff you guys came up with is really
necessary? I appreciate the input and ideas and I agree that it would be
nice, but necessary? Are you sure it's not more trouble than worth at
this point? If a custom tracker should be developed at some point, then
it shouldn't happen behind LAD doors but together with other parties who
could benefit from it and likely have more expertise in that area.
The closest existing thing I know is http://openhatch.org/, which pulls
all or some bugs from lots of trackers, but I'm not sure it's close to
what is needed here.
My idea for the near future was to simply use an existing wiki, possibly
on linuxaudio.org (mainly because of the domain name). In the simplest
form I believe, tags could be used for applications (to find all issues
involving the specific app), pages for the issues and page subscriptions
for notification. I'm no expert on wikis, so I'm not sure whether there
are more features that could be used to fulfill more of what we'd
want.
--- End forwarded message ---
--
Regards,
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
Hi,
I have written a FFTW based block convolution jack client, but I am
having difficulty processing the last jackframes%L samples of the jack
buffer. I have read that it might be an idea to collect the samples
into a second buffer and process them independently of the jack
process callback, but I have no clue how to implement that. Any
suggestions would be appreciated.
I want to use the Parks-McClellin algorithm to generate some FIR
filter coefficents with some user configurable parameters and have it
process the filters using block convolution. Possibly as an addon for
calf?
So far my jack client works, and the block convolution overlap-add
algorithm works as per Oppenheim and Schafer, but the last few samples
of each jack buffer are zeroes.
It would be nice to be able to have FIR filters longer than the size
of the jack buffer too. Any ideas?
---
Damien Zammit
