ooper.
>
sooperlooper allready has this feature, look for the latest releases.
simple MIDI programming with bash/mididings, pd or csound could easily add
the "random" feature to it
olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@list
On 11/12/2011, thijs van severen wrote:
> I must be missing something here.
> amidi -l should list all midi out ports that are available to amidi, right?
> No matter what i try with a2j and all of its variants (including j2a and
> using the -e option) amidi -l never gives me any usable ports.
> Sa
t; option, but can't seem to find a way.
I would be gratefull for any help accomplishing this!
olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Sorry, wrong list!
:-)
olivier
On 1 April 2016 at 12:43, olivier wrote:
> Hi everyone,
>
> I'm looking to display a tracker item in another tracker listing.
>
> eg, I have a "user" tracker named "customers", it contains phone numbers
> for each us
Hi,
is there a way to compute an absolute timetag from the jack position in order
to
send timestamped OSC messages, from the jack process callback?
Regards,
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http
cks, xruns) with many tracks or on slower systems, and I'm
thinking about adding real pitch and time shifting using Rubberband in the near
future, which is certainly going to be a lot heavier.
Is my idea of a helper thread correct? Any clue to set things up properly?
Cheers,
--
Ol
Hi Dan,
why don't you answer on the mailing list?
Dan Mills wrote:
> On Fri, 2008-08-22 at 20:26 +0200, Olivier Guilyardi wrote:
>>
>> In Jackbeat I perform sample rate conversion using libsamplerate in the
>> realtime
>> thread. I have recently realized that
Dan Mills wrote:
> On Sat, 2008-08-23 at 14:56 +0200, Olivier Guilyardi wrote:
>
>>> That is a fairly common approach, one thread per core is good. I have
>>> code that reads audio, sample rate converts it, time-stretches it if
>>> appropriate and sticks it in a
Errata:
Olivier Guilyardi wrote:
[...]
> a buffer of 1024 bytes would do I suppose.
[...]
> This way I could have big ringbuffers (say 64k), to ensure smooth output.
I meant frames (floats) not bytes.
--
Olivier Guilyardi / Samalyse
___
fer size: 8/16
[reader started] [writer started] [flowing] 52572 != 52568 at offset 0
FAILURE in chunk 91822
test-int-array-jack-fix1 - starting (20s max) - array/buffer size: 8/16
[reader started] [writer started] [flowing] SUCCESS
test-int-array-portaudio - starting (20s max) - array/buffer si
n the audio thread, so
that the buffer is almost always full. I think this is quite realistic.
In these conditions, if I understand correctly the result of this test, there
is
a chance for the output of the ringbuffer to differ from its input. Isn't that
some sort of bug?
--
Olivier Guilyardi / Samalyse
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Olivier Guilyardi a écrit :
> Hi,
>
> Pieter Palmers a écrit :
>> Sean Bolton wrote:
>>>
>>>> test-bit-circle-jack - starting (5s max) - buffer size: 512
>>>> || FAILURE: 2 != 514
>>>
>>> I thought it suspicious that 514
Sean Bolton wrote:
> On Oct 20, 2008, at 3:18 PM, Olivier Guilyardi wrote:
>> What about the test-int-array-* family of tests on PPC?
>
> They all pass on my uniprocessor G4, but that doesn't
> really tell us much. Anybody got a multiprocessor PPC?
I think it might be wor
n scheduled to run on the same
processor/core in your first attempt.
In this regard you can try with rbtest at r309:
svn co -r309 http://svn.samalyse.com/misc/rbtest
It prints the cpu on which the threads are started (I deactivated this because
sched_getcpu() was randomly absent or crashing, but
heck the README for more.
[1] http://www.kokkinizita.net/papers/usingdll.pdf
Best regards,
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Stefan Kost wrote:
> Olivier Guilyardi schrieb:
>>
>> [...]
>> However, although my measures are pretty encouraging, I am not 100% sure of
>> my
>> DLL implementation. Could you please review it ? It's there:
>> http://svn.samalyse.com/pendule/trunk/s
that in the case of JACK, one could subtract the
value of jack_frames_since_cycle_start() from the system time passed to
pendule_update(), to get closer to the exact time the current cycle started.
Is this correct to you?
--
Olivier
___
Linux-audio-
Paul Davis wrote:
> On Tue, 2009-01-27 at 13:49 +0100, Olivier Guilyardi wrote:
>
>> For example, in FFmpeg, each audio and video packets are tagged using a PTS
>> which is computed using av_gettime() which calls gettimeofday().
>
> this should be considered a bug and
Michael, Paul has answered you on jack-devel. See below.
Note: I'm cross-posting this mail to linux-audio-dev, since Michael has
recently
subscribed to it. At least, we should be able to discuss together in there.
Paul Davis wrote :
> I have no idea how any of you have kept this conversation go
Hi,
I'm looking for material, docs and/or software to remove speech noise, as caused
by the movements of the mouth.
Any pointer?
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/ma
and synthesis things. With a nice GUI.
Great link. Thanks !
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
alex stone wrote:
>
> On Mon, Mar 9, 2009 at 1:10 PM, Olivier Guilyardi <mailto:l...@samalyse.com>> wrote:
>
> I'm looking for material, docs and/or software to remove speech
> noise, as caused
> by the movements of the mouth.
>
> In the comm
odule 1 spoken=French,
> Module 2 sung=French, Module 3 spoken=Finnish, etc)
I think you're right. There's nothing universal about making noise and actually
meaning something ;)
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
egrates very well into a graphical daw, such as a plugin.
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
what I can do about that, I can't promise anything though.
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
alex stone wrote:
>
> On Mon, Mar 9, 2009 at 2:59 PM, Olivier Guilyardi <mailto:l...@samalyse.com>> wrote:
>
> alex stone wrote:
>
> > If you're intent on automating a speech analysis, voice noise removal
> > device of some sort, then y
bout it though. Btw, what are the available text-based hosts for LV2 plugins?
Does ecasound support them?
Julien, by curiosity, what would you use this speech filter for?
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.
Chris Cannam wrote:
> On Wed, Mar 11, 2009 at 4:15 PM, Olivier Guilyardi wrote:
>> Plus, before removal, visual/auditive review of the detected noises (in some
>> sort of audio editor) sounds quite important: there's alway a risk to
>> confuse a
>> noise with
Julien Claassen wrote:
> Salut Olivier!
> I don't think ecasound does it yet. Except if they are compatible to
> ladspa. I'll have to check. Besides that, there would be a simple
> test-host like applyplugin for LADSPA.
> I'd use this for my own speech recordings.
Paul Davis wrote:
>
>
> On Thu, Mar 12, 2009 at 11:18 AM, Olivier Guilyardi <mailto:l...@samalyse.com>> wrote:
>
> I don't think splitting would do the job. Any chance that the noise
> regions
> reported by the vamp plugin could turn into sel
Paul Davis wrote:
>
> On Thu, Mar 12, 2009 at 11:43 AM, Olivier Guilyardi <mailto:l...@samalyse.com>> wrote:
>
[...]
> Will the regions reported by the vamp plugin turn into selected
> regions in ardour?
>
>
> currently VAMP is used within the
ties, and now even JACK support with
the Juced "fork" (I didn't test this one though).
http://www.rawmaterialsoftware.com/juce/
http://code.google.com/p/juced/
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
d anyone tell me what's wrong with this C code?
Thanks in advance
--
Olivier
blocksize=2048;
args=argv();
if length(args) != 3
printf('Usage: infile nframes outfile\n');
printf('Remark: use nframes=-1 to read the full infile\n');
exit(1)
end
[signal, samplerate, bits
to run with integers (fixed point fft) and the joys
of overflow..
Thanks!
--
Olivier
#include
#include
#include
#include "transform.h"
struct Transform {
int fftsize;
TransformCallback callback;
void * callback_data;
fftwf_plan
to
what's implemented in Audacity:
http://wiki.audacityteam.org/index.php?title=Noise_Removal
I'm however also interested in so-called spectral subtraction. I tend to think
that although it may be simpler, it won't give such good results as the gating,
which are quite
discussed at some considerable length on jack-devel last year, IIRC.
> for single reader/single writer ringbuffers, i believe that we
> concluded that memory barriers are not necessary.
No, to me the conclusion was: we can't programmatically prove that memory
barriers are neede
udio/trunk/src/common/pa_ringbuffer.c
In short, they use memory barriers at only three places, especially:
- "to ensure that previous writes are seen before we update the write index"
- "to ensure that previous writes are always seen before updating the (read)
index."
It should
Okay, I got a patch for Jack1's ringbuffer, it's not finished, but it's a
beginning. I think it misses some "read" memory barriers, as described in
kernel's memory-barriers.txt (in SMP BARRIER PAIRING) : "A write barrier should
always be paired with a d
On 12/17/2009 12:40 PM, Olivier Guilyardi wrote:
> On 12/16/2009 06:57 PM, Tim Blechmann wrote:
>
>>> The point is, I wrote ringbuffer stress tests, and someone reported on this
>>> list
>>> that they succeeded on a weakly-ordered (PowerPC SMP) system, even wi
or this, a workaround for that,... GCC devs are more competent for this I
think, and will keep it up-to-date.
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
On 12/17/2009 04:00 PM, Tim Goetze wrote:
> [Olivier Guilyardi]
>
>> On 12/17/2009 01:03 PM, Tim Blechmann wrote:
>>>> +#if defined(__APPLE__)
>>>> +#include
>>>> +#define MEMORY_BARRIER() OSMemoryBarrier()
>>>> +#elif (__GNUC__
to JACK,
which is easily performed in many cases.
I think this is the way it happens in many circumstances, not only on Linux: an
easy default is provided, and one can optimize his/her setup with a few efforts.
--
Olivier
___
Linux-audio-dev mailin
MIDI solve your problems and remove the need for scheduling,
since it's sample-synchronized with audio?
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
inute, beats_per_bar, etc...) of
jack_position_t.
I also recommend that you look at the (tested) JACK midi example clients.
Hope that helps
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
epos - position.frame;
if (event_offset >= 0 && event_offset < nframes) {
jack_midi_event_write(port_buffer, event_offset, ...);
}
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linux
which neither support JACK Midi (only
ALSA), nor deal or even care about the BBT and BPM info from the jack transport
position.
So you may need to be more specific about which other software you want your app
to interact with, to make a definitive decision about ALSA Midi support, etc...
That sa
oblem.
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 Bea
r, almost only working on Linux.
I really don't think there's such a high entry to the learning curve. It's all
plain C++, and the specific signal/slot syntax is intuitive.
Qt is not such a world apart IMO. I've used Gtk a lot, and I real
/lock-based IPC is not ok.
What I do in this situation is sending messages from one thread to the other
through a jack ringbuffer. This is 100% realtime-safe.
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
On 05/20/2010 10:12 PM, Chris Cannam wrote:
> On Thu, May 20, 2010 at 5:30 PM, Olivier Guilyardi wrote:
>> Qt is really great. I also highly recommend that you look at Qt Creator
>> which is
>> included in the SDK. Although I'm a long time Vim user, I really found this
a choice between the two, and I often end up coding the engine
in C and the rest in C++ or a dynamic language.
But maybe that, with experience and methodology, one can get as productive in C
as in C++? I suppose the guys at Gnome would agree with that..
--
Olivier
_
On 05/24/2010 10:24 AM, torbenh wrote:
> On Sun, May 23, 2010 at 11:07:27PM +0200, Olivier Guilyardi wrote:
[...]
>> 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
On 05/24/2010 01:47 PM, torbenh wrote:
> On Mon, May 24, 2010 at 12:36:43PM +0200, Olivier Guilyardi wrote:
>
>>> then you need to manage most memory yourself again
>> Which may results in choosing a simplified memory model, and thus
>> optimization.
>>
>
On 05/24/2010 06:00 PM, Olivier Guilyardi wrote:
> http://insenvim.sourceforge.net/
Forget about this one, I googled too fast, it's an old and windows-only thing.
But there seem to be good stuff around:
http://www.google.fr/search?q=vim+omnicomplete
--
On 05/24/2010 08:47 PM, torbenh wrote:
> On Mon, May 24, 2010 at 06:00:05PM +0200, Olivier Guilyardi wrote:
>> On 05/24/2010 01:47 PM, torbenh wrote:
>>> On Mon, May 24, 2010 at 12:36:43PM +0200, Olivier Guilyardi wrote:
[...]
I agree with most of what was above.
>>
On 05/25/2010 07:24 AM, torbenh wrote:
> On Mon, May 24, 2010 at 11:37:32PM +0200, Olivier Guilyardi wrote:
[...]
>> That makes me think that the development environment can really completely
>> change the way you perceive a language or framework. There must be something
&g
I'm doing C right now and AFAIK that won't
help.
But there's another thing that I also realized: after spending a few hours in
Eclipse, I found myself a bit "abandoned" in Vim, as if nobody was holding my
hand anymore ;-)
On 05/28/2010 08:07 PM, Ralf Mardorf wrote:
>
>
> Ralf Mardorf wrote:
>> Olivier Guilyardi wrote:
>>> On 05/28/2010 07:36 PM, Ralf Mardorf wrote:
>>>
>>>> Folderol wrote:
>>>>
>>>>> On Fri, 28 May 2010 19:20:54 +
practices?
Cheers,
[1] http://hexler.net/pub/touchosc/touchosc-manual-v1-1.pdf
[2] http://docs.monome.org/doku.php?id=tech:protocol:osc
[3] http://jackbeat.samalyse.org/wiki/BasicUsage#OSCInterface
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio
into the path or be passed as a value? Should indexes be zero-based? Etc..
To be honest, I am very confused about the idea that OSC is some kind of MIDI
successor. The MIDI protocol is a rather defined, with notes, CC, etc..
Whereas OSC just looks like a
a unique address path- this second method would work with even the
most primitive implementation for receiving OSC values, without any need for an
API."
That makes sense to me.
Nevertheless, they seem to be missing the in/out symmetry idea, which I find
very interesting.
--
Olivier
___
On 06/02/2010 12:51 AM, Paul Davis wrote:
> On Tue, Jun 1, 2010 at 4:01 PM, Olivier Guilyardi wrote:
>
>> Whereas OSC just looks like a generic RPC mechanism, thus requiring some
>> development knowledge or custom-made tools.
>
> this is exactly correct.
>
> there
would be useful is that if I file a "bug"
regarding the interaction of app 1,2 and 3, the relative devs get
automatically mailed and can jump in the discussion
Being able to add link(s) to upstream ticket(s), as in launchpad, could also be
useful.
--
Olivier
__
ovember/025738.html
It hides the complexity of buffer management when doing fft+ifft, using a
callback which receives buffers of frequency domain data. The code also deals
with windowing the signal.
--
Olivier
___
Linux-audio-dev mailing list
Linux-a
le high-level Java API, which is full of various
problems which I have worked around to obtain that kind of quality. Thus, I
can't really tell what happens in there.
Have you already heard such things, and know what the cause, whether hardware or
software, is likely to be?
--
Olivier
On 06/11/2010 02:10 PM, Ralf Mardorf wrote:
> Olivier Guilyardi wrote:
>> Here is the sample, it's a musical flute and violin recording:
>> http://sound.samalyse.org/tapemachine/pulsations.wav
>>
>> Listen carefully and you will here small pulsations.
>
>
On 06/11/2010 03:12 PM, Ralf Mardorf wrote:
> Olivier Guilyardi wrote:
>> He also reported the following: "if I rig up a TRRS 3.5 mm jack to XLR
>> adapter
>> and use a "real" microphone the recording seems to be clean (though
>> with other
>> issue
On 06/12/2010 12:10 AM, Geoff Beasley wrote:
> Olivier,
> hard to tell from such a small fragment if it's regular or random.
> it maybe irq swapping, or overload compression built into the card or...
> what card is it? describe the signal chain.
I don't know which sound
nly
place where I have this problem (dunno about LAU and LAA, since I haven't posted
there for a while). Also, it never happens in all my other personal mails.
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://l
plugin programming guide for the complete idiot using a set of
C++ classes. If you are not a complete idiot, you may want to read the LV2 spec
and figure it out for yourself."
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
he plugin. Thus sharing files that reference plugins such as sequencer
sessions or modular synthesizer patches would become more comfortable, as
missing plugins could be fetched automatically (or finding them would be easier,
at least)."
This last sentence seems to clarify the ide
these issues, I have been working on libtimefilter (formerly
libpendule), which is an implementation of Fons' proposal:
http://code.google.com/p/libtimefilter/
Now, last but not least, almost all of these problems would become a souvenir,
if JACK supported OSC ports, as it does for MIDI, an
scaling - the further the mouse is from the center of
> the knob, the coarser the changes in response to whatever motion
> drives changes.
I like it too, but there always are unwanted changes while you go away from the
center. I think that a good workaround could be up and down with fine-tun
ed precision.
It may need some refinement, but some of you may like it. Unfortunately, it
isn't a real Gtk widget class, but it should be reusable in some ways:
http://jackbeat.samalyse.org/browser/trunk/src/gui/slider.c?rev=636
--
Olivier
On 09/07/2010 09:58 PM, Gordon JC Pearce wrote:
> On Tue, 2010-09-07 at 21:44 +0200, Olivier Guilyardi wrote:
>
>> I have been working on an experimental slider in Jackbeat. When untouched it
>> is
>> very small, but big enough to see what the level is. When you click a
solution to
the space problem.
That said, I reckon that adding a few knobs here and there looks cool :) It can
bring some graphical balance and eye-candy, which may be very important. When
you make music, the UI look & feel has some emotional influ
On 09/07/2010 10:51 PM, Gordon JC Pearce wrote:
> On Tue, 2010-09-07 at 22:35 +0200, Olivier Guilyardi wrote:
>
>> That said, I reckon that adding a few knobs here and there looks cool :) It
>> can
>> bring some graphical balance and eye-candy, which may be very important
On 09/08/2010 12:46 AM, Tim E. Real wrote:
> However, I would like to share with you a 'patented' (he he)
> technique I developed a long time ago:
I am contesting the patent, I did start to work on the same idea two years ago
:p
> When the mouse cursor goes to the edge of the screen you
> ha
lors?
http://testing.samalyse.com/lad/widgets/numbers.png
http://testing.samalyse.com/lad/widgets/numbers.svg
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
On 09/10/2010 02:37 AM, Loki Davison wrote:
> On Wed, Sep 8, 2010 at 6:15 AM, Olivier Guilyardi wrote:
>> Actually, I used the fansliders before, in the very same place :) But there
>> were
>> two things that I didn't like:
>> - the way they look, especiall
On 09/10/2010 06:06 PM, hermann wrote:
> Am Freitag, den 10.09.2010, 14:32 +0200 schrieb Olivier Guilyardi:
>> Well, as I previously said, I think that knobs can make sense in
>> certain
>> situations. So I'd rather see the phat knob improved ;) I think that's
need it for our project, so we start to create on.
IMO you should get some inspiration from Phat..
http://phat.berlios.de/
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
On 09/11/2010 10:45 PM, Gordon JC Pearce wrote:
> On Sat, 2010-09-11 at 19:36 +0200, Olivier Guilyardi wrote:
>
>> Also, the phat knob, with its large orange/blue border provides better
>> visualization IMO. I am however quite sad that in both cases, phat and
>> lib
On 09/12/2010 01:35 PM, Thorsten Wilms wrote:
> On Sun, 2010-09-12 at 12:39 +0200, Olivier Guilyardi wrote:
>
>> In regard to phat, if only the SVG, or XCF, or whatever sources were on svn,
>> that would allow to tune the colors, the size, etc... Maybe that the
>> soluti
pixmaps is everything but flexible.
That said I have started to work on a PhatWheel widget, inspired by this thread
and Thorsten's designs.
I don't have much time, but chances are that I'll make it work and add several
options for
On 09/13/2010 04:25 PM, Paul Davis wrote:
> On Mon, Sep 13, 2010 at 9:53 AM, Olivier Guilyardi wrote:
>> On 09/12/2010 02:05 PM, Loki Davison wrote:
>>
>>> Thorsten's design is as always fantastic. :)
>> Agreed, it's a a shame his new knob designs at
>&
On 09/13/2010 04:43 PM, Paul Davis wrote:
> On Mon, Sep 13, 2010 at 10:38 AM, Olivier Guilyardi wrote:
>> On 09/13/2010 04:25 PM, Paul Davis wrote:
>>> On Mon, Sep 13, 2010 at 9:53 AM, Olivier Guilyardi
>>> wrote:
>>>> On 09/12/2010 02:05 PM, Loki Davison
On 09/14/2010 09:14 AM, Thorsten Wilms wrote:
> On Mon, 2010-09-13 at 22:14 +0200, Olivier Guilyardi wrote:
>
>> For the default rendering of the blue part, using
>> GtkStyle.bg[GDK_STATE_SELECTED] seems to make sense since it renders to a
>> color
>> (blue, brown
n Live. I think that Thorsten's
ideas go into that direction, which I do like, and which could fit in a variety
of UIs.
Actually, it's not really a knob. It's a rotary control *and* level meter. I'd
call it a wheel.
--
Olivier
___
On 09/13/2010 04:43 PM, Paul Davis wrote:
> On Mon, Sep 13, 2010 at 10:38 AM, Olivier Guilyardi wrote:
>> On 09/13/2010 04:25 PM, Paul Davis wrote:
>>> On Mon, Sep 13, 2010 at 9:53 AM, Olivier Guilyardi
>>> wrote:
>>>> On 09/12/2010 02:05 PM, Loki Davison
On 09/15/2010 09:38 AM, Igor Brkic wrote:
> On 14.09.2010 22:49, Olivier Guilyardi wrote:
>>
>> I would quite like to have a look at your knob, but ardour3 r7775
>> segfaults
>> here, right after clicking on Apply in the New Session dialog.
>> Attached: output
>
e.
But I feel like there's something more modern about Thorwil's design, especially
the minimal knobs, not the pseudo-realistic ones. Juce's knob looks a bit as a
clock, or some speed meter, which I don't fancy so much.
For the technical part, that's right, Cairo is just fine
On 09/15/2010 04:52 PM, Paul Davis wrote:
> On Tue, Sep 14, 2010 at 4:49 PM, Olivier Guilyardi wrote:
>
>> I would quite like to have a look at your knob, but ardour3 r7775 segfaults
>> here, right after clicking on Apply in the New Session dialog. Attached:
>>
On 09/16/2010 05:01 PM, Paul Davis wrote:
> On Thu, Sep 16, 2010 at 4:52 AM, Olivier Guilyardi wrote:
>
>> I quite like it when it's minimal, not too realistic. It reminds be a bit of
>> the
>> memory/swap meters in the Gnome System Monitor:
>> http
rs with a single knob, a pure software
UI could make use of the first item on the following post:
http://thorwil.wordpress.com/2007/04/22/not-knobs-4/
It is meant to control a range, but there could be other uses I guess.
I can't really think of a real world use-case right now though..
is that IIUC,
the whole Cairo idea defeats the general principle of engines which seem to rely
on the fact that widgets are drawn with gtk_paint_*() functions. Is this
correct?
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
; interfaces designed over the next decade now that multi touch is available
> to us all.
Agreed, 3D UIs are interesting. What you're saying makes me think about Clutter
http://www.clutter-project.org/
Clutter renders with OpenGL, provides Cairo, Pango, and supports multi-touch
IIRC. I think it was primarily meant for mobiles devices but this is not
restrictive.
--
Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
On 09/27/2010 05:42 PM, hermann wrote:
> Am Montag, den 27.09.2010, 15:46 +0200 schrieb Olivier Guilyardi:
>> On 09/27/2010 01:44 PM, Patrick Shirkey wrote:
>>> On Sun, September 26, 2010 1:35 pm, pete shorthose wrote:
>>>> WRT the recent discussion about
On 09/27/2010 06:30 PM, pete shorthose wrote:
> On 27/09/10 14:46, Olivier Guilyardi wrote:
>> On 09/27/2010 01:44 PM, Patrick Shirkey wrote:
>>
>>> On Sun, September 26, 2010 1:35 pm, pete shorthose wrote:
>>>
>>>> WRT the recent d
On 09/27/2010 07:32 PM, hermann wrote:
> Am Montag, den 27.09.2010, 19:13 +0200 schrieb Olivier Guilyardi:
>> On 09/27/2010 05:42 PM, hermann wrote:
>>> Am Montag, den 27.09.2010, 15:46 +0200 schrieb Olivier Guilyardi:
>>>> On 09/27/2010 01:44 PM, Patrick Shirkey wro
1 - 100 of 252 matches
Mail list logo
