Re: [LAD] Jack slower than realtime/debug mode
On Sunday 23 May 2010 04:38:53 Jeremy wrote: Hmm, then it appears to not be a timeout issue. My entire system hung within a few seconds with --timeout 100 I believe you can't really set that timeout greater then 5000. But to test your plugin, why don't you run jack either with dummy backend or with alsa-backend in softmode (ignoring hardware xruns) and without realtime? That should give you a jack that isn't going bersek. Have fun, Arnold signature.asc Description: This is a digitally signed message part. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
On Fri, May 21, 2010 at 11:42:13AM -0700, Niels Mayer wrote:
On Fri, May 21, 2010 at 8:33 AM, torbenh torb...@gmx.de wrote:
and i really find bigger programs pretty confusing in dynamic languages
where variables arent annotated with types.
That's just because the programmer wasn't fastidious enough in naming
variables or structuring the program. You can program badly in any language.
Often dynamic language programs often started as a simple script that
grew... Every program needs refactoring eventually.
i think that code is pretty hard to read.
and concision isnt always good.
To each his own...
sure. i have never liked lisp like languages.
but my main feeling about them, is that you need to write too much.
which seems to be the contrary of how you are arguing.
there is a reason why people call perl a write-only language.
Did I even mention perl? Blech. I was suggesting Clojure and Groovy, for
their readability/elegance/simplicity/ease-of-use and ability to reuse all
of Java classes, JVM advances, portability, wide-adoption, security, etc.
no you didnt mention perl. but perl is often hailed for being so
concise.
Church's work was the inspiration for the development of Lisp as a language.
The able to parallelize any valid faust code is a fundamental corollary to
functional programming and forms the basis of numerous implementations:
http://en.wikipedia.org/wiki/Concurrent_computing (somebody should add Faust
as it's not there, clojure and scala are, and are also much more widely
known).
Clojure, is the next step past that, as it directly integrates language
structures enabling parallelism, along with the functional style needed to
make it all work:
http://clojure.org/agents
overall when it comes to RT stuff either you use a language which
gives you control over heap allocation. or the language must be
specifically designed for RT operation.
so we end up with c/c++ again.
or faust.
And for the things that people do in C or Faust, that's exactly what they
should continue doing.
However, it is simply bad architecture to muddle up RT code with arbitrary
UI code. It's much better to setup a simple network protocol so that the RT
code only need listen on a socket for any I/O related to changing it's
state. Which sounds like exactly the path taken with OSC control of plugins,
etc:
http://dssi.sourceforge.net/why-use.html DSSI separates the plugin and user
interface, using standard Open Sound Control (OSC) messages to communicate
between them. This ensures that the plugin's controls are consistently
externally available, provides a guarantee of automatability, and encourages
clean plugin structure.
And then just write an external UI program that talks OSC and attempts to
keep up as best possible with the realtime processing going on in a
different process. Allowing that realtime process to determine scheduling
and receipt of UI events.
Why muddle-up perfectly good realtime code w/ a bunch of GUI?
the reason why dssi does this is not that things would muddle up.
its a workaround for the Qt and gtk+ dont really work in a single
process problem.
i dont see why implementing 2 things in the same language muddles
anything up. i admit that it does enforce not muddling it up.
but basically you end up with 2 layers of marshalling.
one layer for the marshalling from normal thread to the RT thread.
and another for the osc marshalling.
i consider cpu time pretty precious in RT contexts.
GUIs get pretty sluggish, once the DSP load hits 50%
and this kind of marshalling/copying data around doesnt help at all.
all this stuff you posted is nice... but i dont really have any hopes,
that this stuff would become useable in the next 2 years.
2 years is like 10 in internet time.
stop dreaming :)
But that's what I do!
Looks like I won't have to dream long:
http://github.com/rosejn/midi-clj
http://github.com/rosejn/osc-clj
http://bitbucket.org/amb/clojure-snippets/src/tip/audio.clj
http://github.com/amb/rezo
http://osdir.com/ml/clojure/2010-01/msg00900.html
(defn osc-recv
Receive a single message on an osc path (node) with an optional
timeout.
[peer path [timeout]]
(let [p (promise)]
(osc-handle peer path (fn [msg]
(deliver p msg)
(osc-remove-handler)))
(let [res (try
(if timeout
(.get (future @p) timeout TimeUnit/MILLISECONDS)
@p)
(catch TimeoutException t
nil))]
res)))
I bet the above would combine quite nicely with a
http://qtjambi.sourceforge.net/ GUI via Clojure
hmm... its probably a matter of taste.
but i find the equivalen c++ easier to read.
assuming we have a proper modern c++ osc lib:
boost::unique_futureOscMsg
osc_recv (OscPeer peer, std::string path)
{
boost::shared_ptr boost::promiseOscMsg spromise( new
boost::promiseOscMsg )
peer.add_handler( path, [=]( OscMsg msg )
{
Re: [LAD] precision resampling to correct clock differences - no luck with libsamplerate and zita-resampler...
On Sun, May 23, 2010 at 08:52:16AM +1000, Erik de Castro Lopo wrote: I really don't think any modification is necessary. At least one: the sample rate value in the header must remain the same. The 'canonical' way to obtain the required result would be to modify the input file's header to reflect the real (and wrong) samplerate before it is resampled, then resample it to the exact required rate. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte ! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] precision resampling to correct clock differences - no luck with libsamplerate and zita-resampler...
f...@kokkinizita.net wrote: On Sun, May 23, 2010 at 08:52:16AM +1000, Erik de Castro Lopo wrote: I really don't think any modification is necessary. At least one: the sample rate value in the header must remain the same. sndfile-resample accepts a: -by ratio command line option where ratio is given as a floating point value. After the conversion is done, the sample rate in the destination file's header. The 'canonical' way to obtain the required result would be to modify the input file's header to reflect the real (and wrong) samplerate before it is resampled, then resample it to the exact required rate. Probably easier to fix the desination file. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Jack slower than realtime/debug mode
On Sun, May 23, 2010 at 09:26:20AM +0200, Arnold Krille wrote: On Sunday 23 May 2010 04:38:53 Jeremy wrote: Hmm, then it appears to not be a timeout issue. My entire system hung within a few seconds with --timeout 100 I believe you can't really set that timeout greater then 5000. But to test your plugin, why don't you run jack either with dummy backend or with alsa-backend in softmode (ignoring hardware xruns) and without realtime? That should give you a jack that isn't going bersek. Have fun, Arnold i gathered from irc that you are using jack2. things are a bit different there. if you want timeouts you need to run jack2 in sync mode. dont use RT with a broken plugin. not completely sure though. for this kind of stuff jack1 is better suited, since its using sync mode by default. and it also just kills a client which doesnt behave. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev -- torben Hohn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] precision resampling to correct clock differences - no luck with libsamplerate and zita-resampler...
On 05/23/2010 11:20 AM, Erik de Castro Lopo wrote: f...@kokkinizita.net wrote: On Sun, May 23, 2010 at 08:52:16AM +1000, Erik de Castro Lopo wrote: I really don't think any modification is necessary. At least one: the sample rate value in the header must remain the same. sndfile-resample accepts a: -by ratio command line option where ratio is given as a floating point value. yes, that's what i've used in the end. but as i said in another posting, i've been confused about it, because the ratio is displayed rounded to 6 decimals, and the apparent target rate is an integer (i.e. the number that ends up in the target header), even though the real sample rate is the desired fractional value. After the conversion is done, the sample rate in the destination file's header. The 'canonical' way to obtain the required result would be to modify the input file's header to reflect the real (and wrong) samplerate before it is resampled, then resample it to the exact required rate. Probably easier to fix the desination file. yep. sndfile-convert -override-sample-rate=44100 in.wav out.wav did the trick for me. best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Reminder: upcoming L2Ork workshop at NYC Resistor as part of ICMC 2010
(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) i...@vt.edu http://www.music.vt.edu/faculty/bukvic/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
On Sun, May 23, 2010 at 9:41 AM, torbenh torb...@gmx.de wrote:
but i find the equivalen c++ easier to read.
assuming we have a proper modern c++ osc lib:
boost::unique_futureOscMsg
osc_recv (OscPeer peer, std::string path)
{
boost::shared_ptr boost::promiseOscMsg spromise( new
boost::promiseOscMsg )
peer.add_handler( path, [=]( OscMsg msg )
{
[...]
Is this C++0xthingy?
I have to say this combination of Boost plus Weird Stuff From The
Future is no more readable to me (as a long-time C++ programmer) than
the Clojure example. It looks neat, but I'm pretty sure it's
accessible to you only because it's what you've spent the time with
recently.
I worry about that all the time with my own code -- the more care I
take to use the language well, the less likely anyone else is to be
able to work with it.
Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
On Sat, May 22, 2010 at 11:59 PM, Niels Mayer nielsma...@gmail.com wrote: results so far... using a combination of vamp-plugins, groovyapache-velocityjavascriptflash via xwiki java-based platform http://nielsmayer.com/ts-episode-timeline.png http://nielsmayer.com/ts-episode-evnt-anls.png You sent me email about this, which I shamefully never replied to (my excuses include having been on holiday at the time, getting lots of email generally, being a bit useless etc etc). It is quite impressive to look at. Have you seen SAWA from Gyorgy Fazekas? Another interesting Vamp-based thingumijig. http://www.isophonics.net/content/sonic-annotator-web-application Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
On Sun, May 23, 2010 at 08:44:42PM +0100, Chris Cannam wrote:
On Sun, May 23, 2010 at 9:41 AM, torbenh torb...@gmx.de wrote:
but i find the equivalen c++ easier to read.
assuming we have a proper modern c++ osc lib:
boost::unique_futureOscMsg
osc_recv (OscPeer peer, std::string path)
{
boost::shared_ptr boost::promiseOscMsg spromise( new
boost::promiseOscMsg )
peer.add_handler( path, [=]( OscMsg msg )
{
[...]
Is this C++0xthingy?
I have to say this combination of Boost plus Weird Stuff From The
Future is no more readable to me (as a long-time C++ programmer) than
the Clojure example. It looks neat, but I'm pretty sure it's
accessible to you only because it's what you've spent the time with
recently.
I find this sort of thing absolutely beyond comprehension.
It's impossible to understand without knowing the boost::
abstractions, templates and god knows what else.
IMNSHO, the way any software works should be understandable by
a) knowing the language, b) reading the code, at least up to the
point that the reader can have an good idea of the big picture,
of data structures and control flow, only excluding application
domain specific details which require special expertise anyway.
If libraries are used to somehow extend the language rather for
encapsulating application domain specific algorithms, the net
result is code that is utterly unreadable to anyone who happens
not to use the same libraries. This is true for libs such as STL
and to a larger degree, boost.
Again IMNSHO, a programming language should be used 'as is',
without trying to extend it or introduce concepts that are
not part of it ('shared_ptr', 'promise' (whatever that means),
'spromise' (whatever that means), etc.). All the rest is just
obfusciation, and useful only to some niche of 'believers'.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
On Sun, May 23, 2010 at 4:55 PM, f...@kokkinizita.net wrote:
IMNSHO, the way any software works should be understandable by
a) knowing the language, b) reading the code, at least up to the
point that the reader can have an good idea of the big picture,
of data structures and control flow, only excluding application
domain specific details which require special expertise anyway.
i think that most experienced C++ programmers understand that using
templated libraries effectively transforms the program from being written
in C++ to being written (for example) with boost. if you don't want to
take advantage of the sorts of incredible features that boost offers, thats
fine. the problem is that some of us do, even though we recognize that there
is a very real price to doing so. you start with a little nibble of the STL,
then you dabble with the header-only parts of boost, and finally you're
sucked in.
more seriously: because languages like C do *not* define anything like
container types, *some* template libraries like the STL actually make much
more readable by others: anyone with any level of experience of the STL can
understand how the containers in another STL-using program work and what
their semantic guarantees are. now contrast this with the vast collection of
foobar list implementations that exist for C, now add dynamically-resizing
arrays, hashes and all of a sudden its clear that its much harder for the
average C programmer to have any clue about the subtle details of how these
might work in a given implementation.
Again IMNSHO, a programming language should be used 'as is',
without trying to extend it or introduce concepts that are
not part of it ('shared_ptr', 'promise' (whatever that means),
clearly, you've not used shared_ptr.
after about 2 years of using it, i'm about ready to wonder how, and more
importantly why, i ever wrote any code without it, and perhaps more
importantly, what possible semantic justification there could be for using
anything else (i'm including its cousins like weak_ptr) outside of a device
driver.
'spromise' (whatever that means), etc.). All the rest is just
obfusciation, and useful only to some niche of 'believers'.
i am glad to hear, however, that you've never used longjmp/setjmp in your
code, or thread local storage.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
On 05/23/10 16:22, Chris Cannam wrote:
On Sun, May 23, 2010 at 8:44 PM, Chris Cannam
On Sun, May 23, 2010 at 9:41 AM, torbenhtorb...@gmx.de wrote:
but i find the equivalent c++ easier to read.
assuming we have a proper modern c++ osc lib:
boost::unique_futureOscMsg
osc_recv (OscPeer peer, std::string path)
{
boost::shared_ptr boost::promiseOscMsgspromise( new
boost::promiseOscMsg )
peer.add_handler( path, [=]( OscMsg msg )
{
[...]
can...@all-day-breakfast.com wrote:
I have to say this combination of Boost plus Weird Stuff From The
Future is no more readable to me (as a long-time C++ programmer) than
the Clojure example.
... by which I don't mean to imply that I can't understand it
(although, with C++, there is always the possibility that I _think_ I
can understand it but am sadly mistaken because of some weird shit
happening behind the scenes). I just mean that I can't simply read
it.
This may be one really serious advantage for the everything-in-C types
-- a competent C programmer can understand any C, whereas C++ is big
enough to have many different schools of C++ which are mutually
unintelligible without further study.
That's also the seed of its popularity, I suppose -- everyone can
write the way they like in it, and if you can't work out how to do it
properly, you can always drop back into C.
I think it isn't difficult to read because it is C++ or Boost. It is
difficult to read because it involves concepts like promises and
futures, which are advanced topics that a lot of people (myself
included) aren't adequately familiar with (at least not without
referring to a cheat sheet). If we rewrote that with C types using a C
type future/promise system, I'm not sure it would be any easier to read
for those of us who don't intuitively grok promises and futures.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for an introduction to rt programming with a gui
On 05/23/10 17:14, Olivier Guilyardi wrote: On 05/23/2010 10:22 PM, Chris Cannam wrote: [...] ... by which I don't mean to imply that I can't understand it (although, with C++, there is always the possibility that I _think_ I can understand it but am sadly mistaken because of some weird shit happening behind the scenes). I just mean that I can't simply read it. I once read a great (and funny) article arguing that you simple can't assume anything about what the following means in C++: a = b + c Nothing You can assume quite a bit, if you are willing to assume something that could be wrong. ;) If that doesn't work as expected, then whoever over-rode operator+ and operator= probably need some form of abuse. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
