Re: [LAD] Real-time plotting of audio/ oscilloscope.

[Ralf Mardorf]

Ralf Mardorf wrote:

Ralf Mardorf wrote:

Jeremy wrote:
Is there a fundamental restriction on doing so, or is my problem in 
software?


Jeremy


Hardware ;)!

We should start a black- and whitelist for hardware used for Linux 
real-time. Unfortunately I could add my two machines to the blacklist 
:(.


A blacklist (greylist) was started here, but it's a forum. We should 
do a real 'list' (table) with printable short informations about no-go 
chip sets etc..

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Sorry, here's the link: http://www.64studio.com/node/69
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Real-time plotting of audio/ oscilloscope.

[Ralf Mardorf]

Ralf Mardorf wrote:

Jeremy wrote:
Is there a fundamental restriction on doing so, or is my problem in 
software?


Jeremy


Hardware ;)!

We should start a black- and whitelist for hardware used for Linux 
real-time. Unfortunately I could add my two machines to the blacklist :(.


A blacklist (greylist) was started here, but it's a forum. We should do 
a real 'list' (table) with printable short informations about no-go chip 
sets etc..

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Real-time plotting of audio/ oscilloscope.

[Ralf Mardorf]

Jeremy wrote:
Is there a fundamental restriction on doing so, or is my problem in 
software?


Jeremy


Hardware ;)!

We should start a black- and whitelist for hardware used for Linux 
real-time. Unfortunately I could add my two machines to the blacklist :(.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Ralf Mardorf]

Btw. when 'we' some old dino computer freaks controlled stepper motors 
by DOS machines, we just controlled remoted pics (oldish micro 
controllers - but not very old -, I guess you would use DSPs or other 
micro controllers today, but would you use your MacOS, Windows, Linux 
instead of external chips for fast and exact real-time control?).


Regarding to the age, I should have read who is the sender of the email 
before I replied ;D.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Ralf Mardorf]

Gene Heskett wrote:

On Wednesday 16 June 2010, Philipp Überbacher wrote:
  

Excerpts from Gene Heskett's message of 2010-06-17 00:45:14 +0200:


[...]

  

I fear something named simply 'emc' isn't easy to find around the net.



Try 
  


Thank you :)

I guess I'll have the time to test it on the weekend or within next 
week. Cool :)!

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Ralf Mardorf]

Gene Heskett wrote:

On Wednesday 16 June 2010, Patrick Shirkey wrote:
  

On 06/17/2010 04:52 AM, Ralf Mardorf wrote:


Paul Davis wrote:
  

On Wed, Jun 16, 2010 at 2:30 PM, Ralf Mardorf

 wrote:


PS: Why not programming for savant syndrome musical gifted and 'fast'
watching people too?
  

the limits under discussion relate to monitor technology, not human
capabilities.


I'm not a 'fast watching savant' ;) and even if the GUI is too slow, I
won't care. I'm listening to music with my very good ears, but my bad
eyes. No doubt, Linux is a good choice, but MIDI real-time could be
better. For me the GUI is unimportant. BUT I prefer to do audio
recordings using Linux, but MIDI recordings. It's a real pity, because
MIDI would add some very cool features.
  

This is only on your system right? I know a lot of people are working
with midi recording using linux tools.

You see jitter at low latency but have you tried changing your hardware
or working with the driver developers to isolate and fix the bugs you
are seeing?



One of the test tools that might be enlightening for the MIDI folks here, is 
the machine control program called emc.  Because jitter is very important 
when feeding a stepper motor controller a steady heartbeat at high audio and 
somewhat above frequencies, the coders have developed a 'latency-test' 
script, which you run on one screen, then abuse the heck out of the machine 
doing other things, (browsing the web, moving windows around, compiling a 
kernel, whatever warms up the cpu) then come back half an hour or more later 
and read the average and worst case latencies as displayed in nanoseconds.  

Those are generally big figures so do the math and make milliseconds out of 
them.


Emc when running stepper motors is fussier that all get out, and that tool 
just might point the finger at truly bad motherboard, or video hardware.  
FWIW, an nvida video card, can only be used in a machine running emc if the 
vesa driver is selected, all the others including nv, tie up the interrupts, 
sometimes for many milliseconds.  For emc, that would equal a stalled motor 
and a wrecked part you were cutting at the time it stalled.  Similar things 
can be said about the APCI of some motherboards.  If that can't be fixed via 
a bios setting, toss the board.  Via chipsets seem to be the most popular in 
this latter category.


If its a complex part that you've already got several hours worth of carving 
& cutting tool wear into, that will only happen once, because whatever the 
culprit is, gets both found and a free airmail trip into the bin.


What?  Oh, I'll go back to lurking now. ;-)
  


I guess you are regarding to http://linuxwiki.de/EMC, but I just started 
searching the web. Btw. when 'we' some old dino computer freaks 
controlled stepper motors by DOS machines, we just controlled remoted 
pics (oldish micro controllers - but not very old -, I guess you would 
use DSPs or other micro controllers today, but would you use your MacOS, 
Windows, Linux instead of external chips for fast and exact real-time 
control?). While oldish machines without multitasking, e.g. the Atari ST 
could control machines on real-time, at least for applications like 
MIDI, I don't know if the Atari would be able to control a CNC machine, 
I guess there are reasons for using external micro controllers when 
controlling such machines, not only when using a MacOS, Windows PC, 
Linux PC I never heard of MacOS, Windows PC, Linux PC that are used to 
do it directly, without help of external micro controllers. But I hear - 
never tested it myself - that Nuendo (for Windows) should be the first 
and only MIDI capable PC software.


If jitter for MIDI is depending to chip sets - and I do belief that the 
chip sets are important - why aren't there trustful black- and 
whitelists for that hardware?


I should shut my mouth and lurk too.

Ralf
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Real-time plotting of audio/ oscilloscope.

[Jeremy]

Hi,

When I'm programming, I find it immensely helpful to be able to plot audio
data at different points in its processing, for debugging, and to test new
ideas.

Essentially I want an oscilloscope, which plots each chunk of 1024 samples.

I've tried using libplot, but it seems too slow.  It's causing constant
xruns, even when I only plot every 5th sample.

I thought that maybe libplot was too abstract, and that I needed to draw the
pixels on the screen directly.  I tried using SDL, but it caused excessive
xruns also.  Simply setting 48000 pixels per second was enough to cause the
flow of xruns.  This is  *not* erasing the screen, just drawing the points.
 I'd expect that erasing the screen is the slow part, but apparently not.

At this point I'm not sure if it's even possible to plot the audio data in
realtime.  I did a rough calculation, that on my 2 Ghz cpu, it should have
roughly 40,000 cycles to process each sample.  It seems to me that
considering running the whole plugin only uses 1/4 of my cpu, the other
3 cycles should be plenty to put a pixel on the screen.

So I would guess that something else is the bottleneck, like my video chip,
or maybe the libraries I'm using.

So basically my question is:  Has anyone else had any luck with plotting
audio data in real time, and if so, how?  Is it not possible to plot every
sample, but only a certain percentage of them?  Is there a fundamental
restriction on doing so, or is my problem in software?

Jeremy
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Gene Heskett]

On Wednesday 16 June 2010, Harry Van Haaren wrote:
>> Go see ,
>
>The link you posted doesnt work. It's a .org i think:
>http://wiki.linuxcnc.org
>
>Cheers, -Harry
>
Working from wet ram and its 75 years old, what can I plead except 
oldtimers. ;-)

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The FALAFEL SANDWICH lands on my HEAD and I become a VEGETARIAN ...
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Harry Van Haaren]

> Go see ,
>

The link you posted doesnt work. It's a .org i think:
http://wiki.linuxcnc.org

Cheers, -Harry
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Gene Heskett]

On Wednesday 16 June 2010, Philipp Überbacher wrote:
>Excerpts from Gene Heskett's message of 2010-06-17 00:45:14 +0200:
[...]

>I fear something named simply 'emc' isn't easy to find around the net.

Try 

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
75. I think it should not be doing that...

--Top 100 things you don't want the sysadmin to say
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Gene Heskett]

On Wednesday 16 June 2010, Philipp Überbacher wrote:
>Excerpts from Gene Heskett's message of 2010-06-17 00:45:14 +0200:
>> On Wednesday 16 June 2010, Patrick Shirkey wrote:
>> >On 06/17/2010 04:52 AM, Ralf Mardorf wrote:
>> >> Paul Davis wrote:
>> >>> On Wed, Jun 16, 2010 at 2:30 PM, Ralf Mardorf
>> >>>
>> >>>  wrote:
>>  PS: Why not programming for savant syndrome musical gifted and
>>  'fast' watching people too?
>> >>>
>> >>> the limits under discussion relate to monitor technology, not human
>> >>> capabilities.
>> >>
>> >> I'm not a 'fast watching savant' ;) and even if the GUI is too slow,
>> >> I won't care. I'm listening to music with my very good ears, but my
>> >> bad eyes. No doubt, Linux is a good choice, but MIDI real-time could
>> >> be better. For me the GUI is unimportant. BUT I prefer to do audio
>> >> recordings using Linux, but MIDI recordings. It's a real pity,
>> >> because MIDI would add some very cool features.
>> >
>> >This is only on your system right? I know a lot of people are working
>> >with midi recording using linux tools.
>> >
>> >You see jitter at low latency but have you tried changing your hardware
>> >or working with the driver developers to isolate and fix the bugs you
>> >are seeing?
>>
>> One of the test tools that might be enlightening for the MIDI folks
>> here, is the machine control program called emc.  Because jitter is very
>> important when feeding a stepper motor controller a steady heartbeat at
>> high audio and somewhat above frequencies, the coders have developed a
>> 'latency-test' script, which you run on one screen, then abuse the heck
>> out of the machine doing other things, (browsing the web, moving windows
>> around, compiling a kernel, whatever warms up the cpu) then come back
>> half an hour or more later and read the average and worst case latencies
>> as displayed in nanoseconds.
>>
>> Those are generally big figures so do the math and make milliseconds out
>> of them.
>>
>> Emc when running stepper motors is fussier that all get out, and that
>> tool just might point the finger at truly bad motherboard, or video
>> hardware. FWIW, an nvida video card, can only be used in a machine
>> running emc if the vesa driver is selected, all the others including nv,
>> tie up the interrupts, sometimes for many milliseconds.  For emc, that
>> would equal a stalled motor and a wrecked part you were cutting at the
>> time it stalled.  Similar things can be said about the APCI of some
>> motherboards.  If that can't be fixed via a bios setting, toss the
>> board.  Via chipsets seem to be the most popular in this latter
>> category.
>>
>> If its a complex part that you've already got several hours worth of
>> carving & cutting tool wear into, that will only happen once, because
>> whatever the culprit is, gets both found and a free airmail trip into
>> the bin.
>>
>> What?  Oh, I'll go back to lurking now. ;-)
>
>I fear something named simply 'emc' isn't easy to find around the net.
>
Go see , I am reasonable sure there are links to a 
downloadable live but installable .iso there.  You can run this latency-test 
from the booted cd I believe.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Duct tape is like the force.  It has a light side, and a dark side, and
it holds the universe together ...
-- Carl Zwanzig
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Philipp Überbacher]

Excerpts from Gene Heskett's message of 2010-06-17 00:45:14 +0200:
> On Wednesday 16 June 2010, Patrick Shirkey wrote:
> >On 06/17/2010 04:52 AM, Ralf Mardorf wrote:
> >> Paul Davis wrote:
> >>> On Wed, Jun 16, 2010 at 2:30 PM, Ralf Mardorf
> >>>
> >>>  wrote:
>  PS: Why not programming for savant syndrome musical gifted and 'fast'
>  watching people too?
> >>>
> >>> the limits under discussion relate to monitor technology, not human
> >>> capabilities.
> >>
> >> I'm not a 'fast watching savant' ;) and even if the GUI is too slow, I
> >> won't care. I'm listening to music with my very good ears, but my bad
> >> eyes. No doubt, Linux is a good choice, but MIDI real-time could be
> >> better. For me the GUI is unimportant. BUT I prefer to do audio
> >> recordings using Linux, but MIDI recordings. It's a real pity, because
> >> MIDI would add some very cool features.
> >
> >This is only on your system right? I know a lot of people are working
> >with midi recording using linux tools.
> >
> >You see jitter at low latency but have you tried changing your hardware
> >or working with the driver developers to isolate and fix the bugs you
> >are seeing?
> 
> One of the test tools that might be enlightening for the MIDI folks here, is 
> the machine control program called emc.  Because jitter is very important 
> when feeding a stepper motor controller a steady heartbeat at high audio and 
> somewhat above frequencies, the coders have developed a 'latency-test' 
> script, which you run on one screen, then abuse the heck out of the machine 
> doing other things, (browsing the web, moving windows around, compiling a 
> kernel, whatever warms up the cpu) then come back half an hour or more later 
> and read the average and worst case latencies as displayed in nanoseconds.  
> 
> Those are generally big figures so do the math and make milliseconds out of 
> them.
> 
> Emc when running stepper motors is fussier that all get out, and that tool 
> just might point the finger at truly bad motherboard, or video hardware.  
> FWIW, an nvida video card, can only be used in a machine running emc if the 
> vesa driver is selected, all the others including nv, tie up the interrupts, 
> sometimes for many milliseconds.  For emc, that would equal a stalled motor 
> and a wrecked part you were cutting at the time it stalled.  Similar things 
> can be said about the APCI of some motherboards.  If that can't be fixed via 
> a bios setting, toss the board.  Via chipsets seem to be the most popular in 
> this latter category.
> 
> If its a complex part that you've already got several hours worth of carving 
> & cutting tool wear into, that will only happen once, because whatever the 
> culprit is, gets both found and a free airmail trip into the bin.
> 
> What?  Oh, I'll go back to lurking now. ;-)
> 
> -- 
> Cheers, Gene
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> The policy is not to have policy. It works as well in kernel design as 
> politics.
> 
> - Alan Cox on linux-kernel

I fear something named simply 'emc' isn't easy to find around the net.
-- 
Regards,
Philipp

--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle 
Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Gene Heskett]

On Wednesday 16 June 2010, Patrick Shirkey wrote:
>On 06/17/2010 04:52 AM, Ralf Mardorf wrote:
>> Paul Davis wrote:
>>> On Wed, Jun 16, 2010 at 2:30 PM, Ralf Mardorf
>>>
>>>  wrote:
 PS: Why not programming for savant syndrome musical gifted and 'fast'
 watching people too?
>>>
>>> the limits under discussion relate to monitor technology, not human
>>> capabilities.
>>
>> I'm not a 'fast watching savant' ;) and even if the GUI is too slow, I
>> won't care. I'm listening to music with my very good ears, but my bad
>> eyes. No doubt, Linux is a good choice, but MIDI real-time could be
>> better. For me the GUI is unimportant. BUT I prefer to do audio
>> recordings using Linux, but MIDI recordings. It's a real pity, because
>> MIDI would add some very cool features.
>
>This is only on your system right? I know a lot of people are working
>with midi recording using linux tools.
>
>You see jitter at low latency but have you tried changing your hardware
>or working with the driver developers to isolate and fix the bugs you
>are seeing?

One of the test tools that might be enlightening for the MIDI folks here, is 
the machine control program called emc.  Because jitter is very important 
when feeding a stepper motor controller a steady heartbeat at high audio and 
somewhat above frequencies, the coders have developed a 'latency-test' 
script, which you run on one screen, then abuse the heck out of the machine 
doing other things, (browsing the web, moving windows around, compiling a 
kernel, whatever warms up the cpu) then come back half an hour or more later 
and read the average and worst case latencies as displayed in nanoseconds.  

Those are generally big figures so do the math and make milliseconds out of 
them.

Emc when running stepper motors is fussier that all get out, and that tool 
just might point the finger at truly bad motherboard, or video hardware.  
FWIW, an nvida video card, can only be used in a machine running emc if the 
vesa driver is selected, all the others including nv, tie up the interrupts, 
sometimes for many milliseconds.  For emc, that would equal a stalled motor 
and a wrecked part you were cutting at the time it stalled.  Similar things 
can be said about the APCI of some motherboards.  If that can't be fixed via 
a bios setting, toss the board.  Via chipsets seem to be the most popular in 
this latter category.

If its a complex part that you've already got several hours worth of carving 
& cutting tool wear into, that will only happen once, because whatever the 
culprit is, gets both found and a free airmail trip into the bin.

What?  Oh, I'll go back to lurking now. ;-)

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The policy is not to have policy. It works as well in kernel design as 
politics.

- Alan Cox on linux-kernel
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] audio/midi app development

[Ralf Mardorf]

A PPPscriptum:

When I programmed for 65xx and 68xxx CPUs on Basic + Assembler I did 
count process cycles for the op codes. Do you know exactly what the 
result is, after you compiled your C code?


Don't believe me, but ask some classic musicians to do some MIDI 
recordings using Linux + external equipment (internal Linux MIDI is ok) 
and then ask them, if they are fine with the result.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Ralf Mardorf]

Ralf Mardorf wrote:

Patrick Shirkey wrote:

On 06/17/2010 04:52 AM, Ralf Mardorf wrote:

Paul Davis wrote:

On Wed, Jun 16, 2010 at 2:30 PM, Ralf Mardorf
 wrote:


PS: Why not programming for savant syndrome musical gifted and 'fast'
watching people too?


the limits under discussion relate to monitor technology, not human
capabilities.


I'm not a 'fast watching savant' ;) and even if the GUI is too slow, 
I won't care. I'm listening to music with my very good ears, but my 
bad eyes. No doubt, Linux is a good choice, but MIDI real-time could 
be better. For me the GUI is unimportant. BUT I prefer to do audio 
recordings using Linux, but MIDI recordings. It's a real pity, 
because MIDI would add some very cool features.


This is only on your system right? I know a lot of people are working 
with midi recording using linux tools.


You see jitter at low latency but have you tried changing your 
hardware or working with the driver developers to isolate and fix the 
bugs you are seeing?


PS:

Sesame Street: Herbie Hancock Makes Sounds
http://www.youtube.com/watch?v=oKoisNv1ftw

The Fairlight CMI. Try to record the backing with a CMI or an Atari ST 
and compare it with Linux MIDI controlling external MIDI equipment. 
Good look!


PPS: Regarding to the groove at the beginning of the video, not to the 
sampling ;). Btw. a nice wristwatch Herbie did wear :D.


:)
Ralf
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Ralf Mardorf]

Patrick Shirkey wrote:

On 06/17/2010 04:52 AM, Ralf Mardorf wrote:

Paul Davis wrote:

On Wed, Jun 16, 2010 at 2:30 PM, Ralf Mardorf
 wrote:


PS: Why not programming for savant syndrome musical gifted and 'fast'
watching people too?


the limits under discussion relate to monitor technology, not human
capabilities.


I'm not a 'fast watching savant' ;) and even if the GUI is too slow, 
I won't care. I'm listening to music with my very good ears, but my 
bad eyes. No doubt, Linux is a good choice, but MIDI real-time could 
be better. For me the GUI is unimportant. BUT I prefer to do audio 
recordings using Linux, but MIDI recordings. It's a real pity, 
because MIDI would add some very cool features.


This is only on your system right? I know a lot of people are working 
with midi recording using linux tools.


You see jitter at low latency but have you tried changing your 
hardware or working with the driver developers to isolate and fix the 
bugs you are seeing?


PS:

Sesame Street: Herbie Hancock Makes Sounds
http://www.youtube.com/watch?v=oKoisNv1ftw

The Fairlight CMI. Try to record the backing with a CMI or an Atari ST 
and compare it with Linux MIDI controlling external MIDI equipment. Good 
look!

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] qjackctl & server name

[fons]

On Wed, Jun 16, 2010 at 06:41:02PM +0100, Rui Nuno Capela wrote:

> ok. fixed (qjackcl 0.3.6.29+)

Works nicely, thanks !

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] audio/midi app development

[Ralf Mardorf]

Patrick Shirkey wrote:

On 06/17/2010 04:52 AM, Ralf Mardorf wrote:

Paul Davis wrote:

On Wed, Jun 16, 2010 at 2:30 PM, Ralf Mardorf
 wrote:


PS: Why not programming for savant syndrome musical gifted and 'fast'
watching people too?


the limits under discussion relate to monitor technology, not human
capabilities.


I'm not a 'fast watching savant' ;) and even if the GUI is too slow, 
I won't care. I'm listening to music with my very good ears, but my 
bad eyes. No doubt, Linux is a good choice, but MIDI real-time could 
be better. For me the GUI is unimportant. BUT I prefer to do audio 
recordings using Linux, but MIDI recordings. It's a real pity, 
because MIDI would add some very cool features.


This is only on your system right?


No!


I know a lot of people are working with midi recording using linux tools.

You see jitter at low latency but have you tried changing your 
hardware or working with the driver developers to isolate and fix the 
bugs you are seeing?


Yesno!

I guess it's OT here what I experienced.

I just wonder that computers >= 1 GHz could have issues, while hardware 
from the 80ies < 1 MHz is completely in sync.


No doubt, my computer is a low-cost computer, even my 80ies 4-track 
recording equipment is much more expensive, but I noticed the same when 
doing jobs for audio and video studios with very good MacOs and Windows 
PCs, MIDI isn't capable on most modern computers.


What would you call reasonable jitter for MIDI? 5 ms are inaudible 
regarding to some audio stuff, but for syncopation less than 1 ms is a 
no-go. You might record the Pet Shop Boys using Linux MIDI, but also try 
to interpret Weather Report.


It's similar to the refresh rate. We aren't able to count how often a 
light would flash, but we are able to recognize the difference between a 
screen that refresh vertically at 60 Hz or above 75 Hz. Everybody is 
able to do that, not only highly gifted autistic savants.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Ralf Mardorf]

hermann wrote:

Am Mittwoch, den 16.06.2010, 21:48 +0200 schrieb Ralf Mardorf:
  

Paul Davis wrote:


On Wed, Jun 16, 2010 at 2:30 PM, Ralf Mardorf
 wrote:

  
  

PS: Why not programming for savant syndrome musical gifted and 'fast'
watching people too?



the limits under discussion relate to monitor technology, not human
capabilities.
  
  
100 Hz for a 32-bit Linux install and 89.9 Hz for my 64-bit Linux 
installs on my machine. I guess I could increase the VF. Anyway,


NTSC 60 Hz, 480 vertical pixels (digital 525 analog to anolog ;)

PAL (50 Hz, 576vertical pixel (digital anlog to anlog 625 *lol*)

Sorry, it's a Wiki on German only, but even the translation is 
unimportant, http://de.wikipedia.org/wiki/Bildwiederholfrequenz.


Musicians are musicians and of course the today so called 'savant 
syndrome' isn't an exception for musicians.


The yardstick for musicians isn't the same as for 'consumers'.

Phew, I know a lot of other jobs, were I could become rich, but instead 
I'm addicted to music.


There might be some (so called) savants, who need a GUIs that will 
refresh near to 100Hz.


Do you program consumer software or apps for professionals?

A rhetorical question.

In a perfect world, a GUI at least should refresh around 75 
times/second. AGAIN I don't need it, but it's a valid wish for people 
who are able to 'watch faster'.


- Ralf



25 times/second is good for me

greats  hermann
  


Regarding to music around 6 times for the GUI would be good enough for 
me. But some musicians might wish to have a visual control that is much 
better, because they are able to notice it. Computers today do have at 
least an operation code frequency around 1 GHz, so sync for the GUI 
shouldn't be an issue. Hm, I'm an old dino, I did program for the C64 
and some other computers on assembler ... much slower than computers 
today, but regarding to MIDI much nearer to the humans recording.


There is an issue for MIDI real-time ... btw. it's not really better for 
Windows PCs, but it's much better for some stand-alone MIDI equipment 
and the C64 or Atari ST.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Patrick Shirkey]

On 06/17/2010 04:52 AM, Ralf Mardorf wrote:

Paul Davis wrote:

On Wed, Jun 16, 2010 at 2:30 PM, Ralf Mardorf
 wrote:


PS: Why not programming for savant syndrome musical gifted and 'fast'
watching people too?


the limits under discussion relate to monitor technology, not human
capabilities.


I'm not a 'fast watching savant' ;) and even if the GUI is too slow, I 
won't care. I'm listening to music with my very good ears, but my bad 
eyes. No doubt, Linux is a good choice, but MIDI real-time could be 
better. For me the GUI is unimportant. BUT I prefer to do audio 
recordings using Linux, but MIDI recordings. It's a real pity, because 
MIDI would add some very cool features.


This is only on your system right? I know a lot of people are working 
with midi recording using linux tools.


You see jitter at low latency but have you tried changing your hardware 
or working with the driver developers to isolate and fix the bugs you 
are seeing?





--
Patrick Shirkey
Boost Hardware Ltd

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[hermann]

Am Mittwoch, den 16.06.2010, 21:48 +0200 schrieb Ralf Mardorf:
> Paul Davis wrote:
> > On Wed, Jun 16, 2010 at 2:30 PM, Ralf Mardorf
> >  wrote:
> >
> >   
> >> PS: Why not programming for savant syndrome musical gifted and 'fast'
> >> watching people too?
> >> 
> >
> > the limits under discussion relate to monitor technology, not human
> > capabilities.
> >   
> 
> 100 Hz for a 32-bit Linux install and 89.9 Hz for my 64-bit Linux 
> installs on my machine. I guess I could increase the VF. Anyway,
> 
> NTSC 60 Hz, 480 vertical pixels (digital 525 analog to anolog ;)
> 
> PAL (50 Hz, 576vertical pixel (digital anlog to anlog 625 *lol*)
> 
> Sorry, it's a Wiki on German only, but even the translation is 
> unimportant, http://de.wikipedia.org/wiki/Bildwiederholfrequenz.
> 
> Musicians are musicians and of course the today so called 'savant 
> syndrome' isn't an exception for musicians.
> 
> The yardstick for musicians isn't the same as for 'consumers'.
> 
> Phew, I know a lot of other jobs, were I could become rich, but instead 
> I'm addicted to music.
> 
> There might be some (so called) savants, who need a GUIs that will 
> refresh near to 100Hz.
> 
> Do you program consumer software or apps for professionals?
> 
> A rhetorical question.
> 
> In a perfect world, a GUI at least should refresh around 75 
> times/second. AGAIN I don't need it, but it's a valid wish for people 
> who are able to 'watch faster'.
> 
> - Ralf

25 times/second is good for me

greats  hermann

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Ralf Mardorf]

Paul Davis wrote:

On Wed, Jun 16, 2010 at 2:30 PM, Ralf Mardorf
 wrote:

  

PS: Why not programming for savant syndrome musical gifted and 'fast'
watching people too?



the limits under discussion relate to monitor technology, not human
capabilities.
  


100 Hz for a 32-bit Linux install and 89.9 Hz for my 64-bit Linux 
installs on my machine. I guess I could increase the VF. Anyway,


NTSC 60 Hz, 480 vertical pixels (digital 525 analog to anolog ;)

PAL (50 Hz, 576vertical pixel (digital anlog to anlog 625 *lol*)

Sorry, it's a Wiki on German only, but even the translation is 
unimportant, http://de.wikipedia.org/wiki/Bildwiederholfrequenz.


Musicians are musicians and of course the today so called 'savant 
syndrome' isn't an exception for musicians.


The yardstick for musicians isn't the same as for 'consumers'.

Phew, I know a lot of other jobs, were I could become rich, but instead 
I'm addicted to music.


There might be some (so called) savants, who need a GUIs that will 
refresh near to 100Hz.


Do you program consumer software or apps for professionals?

A rhetorical question.

In a perfect world, a GUI at least should refresh around 75 
times/second. AGAIN I don't need it, but it's a valid wish for people 
who are able to 'watch faster'.


- Ralf
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Ralf Mardorf]

Paul Davis wrote:

On Wed, Jun 16, 2010 at 2:30 PM, Ralf Mardorf
 wrote:

  

PS: Why not programming for savant syndrome musical gifted and 'fast'
watching people too?



the limits under discussion relate to monitor technology, not human
capabilities.
  


I'm not a 'fast watching savant' ;) and even if the GUI is too slow, I 
won't care. I'm listening to music with my very good ears, but my bad 
eyes. No doubt, Linux is a good choice, but MIDI real-time could be 
better. For me the GUI is unimportant. BUT I prefer to do audio 
recordings using Linux, but MIDI recordings. It's a real pity, because 
MIDI would add some very cool features.


2 cents,
Ralf
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Paul Davis]

On Wed, Jun 16, 2010 at 2:30 PM, Ralf Mardorf
 wrote:

> PS: Why not programming for savant syndrome musical gifted and 'fast'
> watching people too?

the limits under discussion relate to monitor technology, not human
capabilities.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Ralf Mardorf]

Ralf Mardorf wrote:

Arnold Krille wrote:

On Tuesday 15 June 2010 17:55:56 Paul Davis wrote:
 
On Tue, Jun 15, 2010 at 11:27 AM, James Morris  
wrote:
   

Incidentally, if I want the GUI to update very close to real time, say
a grid of blocks flashing on and off as notes come and go, any
thoughts? Would a GTK GUI update fast enough?
  

key insight: your display monitor only redraws between 60 and 90 times
per second. attempting to redraw anything more frequently than this is
simply wasting CPU cycles and making your life more difficult. put
more bluntly: it doesn't matter if you have notes turning on and off
1000 times per second - you and your users not working on a display
device that can possibly show this.



Unless you make your lights "slowly" go on an off with transitions, 
there isn't even a need to be faster then 25 or 30 updates per 
second. The slowest part here is the human eye. And the requirement 
for >60Hz refresh rate for pictures comes from the good old days of 
CRT screens.


Arnold


Because I'm doing graphical art work some times I still prefer old 
faithful CTR screens, currently the refresh rate of my monitor is at 
89.9 Hz. But to be honest, the MIDI-thru-box I build in the 80ies and 
I'm still using it today, has a LED and the light is 'slowly' ... we 
aren't birds ... humans are fine with less than 30 frames/second for 
films and I guess nobody, excepted of some autistic people, are/is 
able to count how often a light is turning of and on within e.g. 30 
frames/second, but we notice any refresh rate under 75 Hz.


Regarding to updates for real-time GUIs it might be not important to 
display a virtual LED showing each MIDI event, but I can confirm that 
an ATARI ST + blitter (a coprocessor) has a more real-time near GUI 
for MIDI events, than Linux on my 2.1 GHz dual-core AMD. I'm not sure 
if it's needed. I also did use Atari STs without a blitter and the 
GUIs are less real-time than my Linux machine.


But this reminds me to my trouble using Linux MIDI with external 
equipment. There is jitter, that by theory isn't audible, but de facto 
it's audible, at least for chamber music like jazz.


Indeed IMO there should be more real-time for MIDI real-time on Linux.

The same old 2 cents,
Ralf


PS: Why not programming for savant syndrome musical gifted and 'fast' 
watching people too?

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Ralf Mardorf]

Arnold Krille wrote:

On Tuesday 15 June 2010 17:55:56 Paul Davis wrote:
  

On Tue, Jun 15, 2010 at 11:27 AM, James Morris  wrote:


Incidentally, if I want the GUI to update very close to real time, say
a grid of blocks flashing on and off as notes come and go, any
thoughts? Would a GTK GUI update fast enough?
  

key insight: your display monitor only redraws between 60 and 90 times
per second. attempting to redraw anything more frequently than this is
simply wasting CPU cycles and making your life more difficult. put
more bluntly: it doesn't matter if you have notes turning on and off
1000 times per second - you and your users not working on a display
device that can possibly show this.



Unless you make your lights "slowly" go on an off with transitions, there isn't 
even a need to be faster then 25 or 30 updates per second. The slowest part 
here is the human eye. And the requirement for >60Hz refresh rate for pictures 
comes from the good old days of CRT screens.


Arnold


Because I'm doing graphical art work some times I still prefer old 
faithful CTR screens, currently the refresh rate of my monitor is at 
89.9 Hz. But to be honest, the MIDI-thru-box I build in the 80ies and 
I'm still using it today, has a LED and the light is 'slowly' ... we 
aren't birds ... humans are fine with less than 30 frames/second for 
films and I guess nobody, excepted of some autistic people, are/is able 
to count how often a light is turning of and on within e.g. 30 
frames/second, but we notice any refresh rate under 75 Hz.


Regarding to updates for real-time GUIs it might be not important to 
display a virtual LED showing each MIDI event, but I can confirm that an 
ATARI ST + blitter (a coprocessor) has a more real-time near GUI for 
MIDI events, than Linux on my 2.1 GHz dual-core AMD. I'm not sure if 
it's needed. I also did use Atari STs without a blitter and the GUIs are 
less real-time than my Linux machine.


But this reminds me to my trouble using Linux MIDI with external 
equipment. There is jitter, that by theory isn't audible, but de facto 
it's audible, at least for chamber music like jazz.


Indeed IMO there should be more real-time for MIDI real-time on Linux.

The same old 2 cents,
Ralf
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] qjackctl & server name

[Rui Nuno Capela]

On 06/16/2010 05:01 PM, f...@kokkinizita.net wrote:
> On Wed, Jun 16, 2010 at 04:51:04PM +0200, Dominic Sacré wrote:
> 
>> Assuming this is the same issue as Fons':
>> When I try to start JACK the second time (after resolving whatever the 
>> problem was), JACK actually starts just fine. I can connect other 
>> clients to it, but QjackCtl itself fails to connect to the server and 
>> stays in the "Starting" state forever. Changing the start delay doesn't 
>> make any difference.
> 
> Confirmed.
> 

ok. fixed (qjackcl 0.3.6.29+)

thanks
-- 
rncbc aka Rui Nuno Capela
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio/midi app development

[Arnold Krille]

On Tuesday 15 June 2010 17:55:56 Paul Davis wrote:
> On Tue, Jun 15, 2010 at 11:27 AM, James Morris  wrote:
> > Incidentally, if I want the GUI to update very close to real time, say
> > a grid of blocks flashing on and off as notes come and go, any
> > thoughts? Would a GTK GUI update fast enough?
> 
> key insight: your display monitor only redraws between 60 and 90 times
> per second. attempting to redraw anything more frequently than this is
> simply wasting CPU cycles and making your life more difficult. put
> more bluntly: it doesn't matter if you have notes turning on and off
> 1000 times per second - you and your users not working on a display
> device that can possibly show this.

Unless you make your lights "slowly" go on an off with transitions, there isn't 
even a need to be faster then 25 or 30 updates per second. The slowest part 
here is the human eye. And the requirement for >60Hz refresh rate for pictures 
comes from the good old days of CRT screens.

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] qjackctl & server name

[fons]

On Wed, Jun 16, 2010 at 04:51:04PM +0200, Dominic Sacré wrote:

> Assuming this is the same issue as Fons':
> When I try to start JACK the second time (after resolving whatever the 
> problem was), JACK actually starts just fine. I can connect other 
> clients to it, but QjackCtl itself fails to connect to the server and 
> stays in the "Starting" state forever. Changing the start delay doesn't 
> make any difference.

Confirmed.

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] [LAU] PaulStretch and JACK

[Louigi Verona]

On Sat, Jun 12, 2010 at 11:10 PM, Mike Cookson  wrote:

> 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.
> ___
> Linux-audio-user mailing list
> linux-audio-u...@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user
>



This is an interesting question. Can any of the devs comment? Did anyone
ever poke around PaulStretch code?

-- 
Louigi Verona
http://www.louigiverona.ru/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] qjackctl & server name

[Dominic Sacré]

On Wednesday 16 June 2010 16:23:05 Rui Nuno Capela wrote:
> > Doesn't work as expected. Whan 'Start' fails it seems to
> > leave qjackctl in an unusable state. Fixing the cause of
> > the failed start doesn't help, the only solution seems to
> > be to terminate and restrart qjackctl itself.
> 
> what you mean by "unusable" state? does it hang? crash? can't 'Start'
> again? what's the cause for the start failure? are there any error
> messages? does it help increasing the start delay?

Assuming this is the same issue as Fons':
When I try to start JACK the second time (after resolving whatever the 
problem was), JACK actually starts just fine. I can connect other 
clients to it, but QjackCtl itself fails to connect to the server and 
stays in the "Starting" state forever. Changing the start delay doesn't 
make any difference.


Dominic

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] qjackctl & server name

[Rui Nuno Capela]

On Wed, 16 Jun 2010 15:13:15 +0200, f...@kokkinizita.net wrote:
> On Wed, Jun 16, 2010 at 09:27:31AM +0100, Rui Nuno Capela wrote:
> 
>> commited to svn trunk (qjackctl 0.3.6.28+)
>> 
>> - Client connection retrial logic scrapped. Being a leftover
>>   from early ages, when machines were slower and JACK server
>>   startup times were longer... now, if it can't connect first
>>   time as client, it will tear down the server whether it's
>>   starting up still or not at all. (cf. Setup/Settings/Start
>>   Delay for the rescue).
> 
> Doesn't work as expected. Whan 'Start' fails it seems to
> leave qjackctl in an unusable state. Fixing the cause of
> the failed start doesn't help, the only solution seems to
> be to terminate and restrart qjackctl itself.
> 

what you mean by "unusable" state? does it hang? crash? can't 'Start'
again? what's the cause for the start failure? are there any error
messages? does it help increasing the start delay?

please
-- 
rncbc aka Rui Nuno Capela
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] qjackctl & server name

[fons]

On Wed, Jun 16, 2010 at 09:27:31AM +0100, Rui Nuno Capela wrote:

> commited to svn trunk (qjackctl 0.3.6.28+)
> 
> - Client connection retrial logic scrapped. Being a leftover
>   from early ages, when machines were slower and JACK server
>   startup times were longer... now, if it can't connect first
>   time as client, it will tear down the server whether it's
>   starting up still or not at all. (cf. Setup/Settings/Start
>   Delay for the rescue).

Doesn't work as expected. Whan 'Start' fails it seems to
leave qjackctl in an unusable state. Fixing the cause of
the failed start doesn't help, the only solution seems to
be to terminate and restrart qjackctl itself.

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

[LAD] audio/midi app development

[Harry Van Haaren]

> 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..)
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] qjackctl & server name

[fons]

On Wed, Jun 16, 2010 at 09:01:58AM +0100, Rui Nuno Capela wrote:

> fwiw, the retry logic is there since dawn. i can assure you it's been
> there for half a decade now ;) it's there for making sure qjackctl connects
> to the starting jackd server as a client of its own.

If the logic was there since the start of time, are you
sure it was working ? I've been using qjackctl for ages,
and *never* noticed this auto retry before half a year
ago ro so. Nor did I ever see it mentioned on the list
before that time.

> the retrial code path will be scrapped asap. the only
> way for you to avoid qjackctl being stalled due to a
> (very) slow jackd startup is now giving it a slack via
> the start delay configuration setting (cf Setup/Settings/Start
> Delay).

This seems to confuse two things:

- the delay between 1) starting the jackd process and
  2) trying to connect to it (which is indeed required),

- auto retrying when things fail.

When either step fails, AFAIK qjackctl is not 'stalled'.
You can (could) just fix the problem and try start again,
no problem at all.

Anyway, if the auto retry goes away I'll be happy.

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] qjackctl & server name

[Rui Nuno Capela]

On Wed, 16 Jun 2010 09:01:58 +0100, Rui Nuno Capela wrote:
> 
> fwiw, the retry logic is there since dawn. i can assure you it's been
> there for half a decade now ;) it's there for making sure qjackctl
connects
> to the starting jackd server as a client of its own.
> 
> indeed, this logic is some kind of a leftover from the early days. when
> machines were slower (in errors per second:) and jackd had some
> considerable startup overhead before stabilizing to accept client
> connections.
> 
> the delay between retrials is/was even progressive ie. each retrial
takes
> a bit longer then the one before, but that's now irrelevant i'm afraid
;)
> 
> the retrial code path will be scrapped asap. the only way for you to
avoid
> qjackctl being stalled due to a (very) slow jackd startup is now giving
it
> a slack via the start delay configuration setting (cf
Setup/Settings/Start
> Delay).
> 

commited to svn trunk (qjackctl 0.3.6.28+)

- Client connection retrial logic scrapped. Being a leftover
  from early ages, when machines were slower and JACK server
  startup times were longer... now, if it can't connect first
  time as client, it will tear down the server whether it's
  starting up still or not at all. (cf. Setup/Settings/Start
  Delay for the rescue).

cheers
-- 
rncbc aka Rui Nuno Capela
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] qjackctl & server name

[Rui Nuno Capela]

On Tue, 15 Jun 2010 17:53:18 -0700, Fernando Lopez-Lezcano
 wrote:
> On Tue, 2010-06-15 at 22:37 +0200, f...@kokkinizita.net wrote:
>> On Tue, Jun 15, 2010 at 09:26:16PM +0100, Rui Nuno Capela wrote:
>> > but in a "normal" desktop environment they should not stack up, the
one
>> > just replaces the one before, which stays there for 3 seconds
maximum.
>> 
>> They don't stack up, but even without that the automatic
>> retrial is just a big nuisance. In 99.99% of all cases it
>> doesn't help, it just keeps on repeating itself, and there
>> is no way to stop it.  At least, [Retry?] should be an
>> option, but even that is quite useless as pressing [Start]
>> again is just as easy.
>> 
>> When starting Jackd fails, two windows pop up. My first reaction
>> is to click [Setup] to find out what's wrong. So now we have
>> three windows (plus the main one) open. Editing the setup (if
>> the error is there) doesn't help, and getting out of all this
>> is just a big mess as Qjackctl won't accept the main close 
>> button as long as any other of its windows is open (why ?),
>> and they just keep coming back.
>> 
>> So *please* remove this, it's just a big nuisance and I don't
>> see in what situation it could ever be useful.
> 
> I have found the qjackctl automatic retry to not help at all as well. 
> 
> I would really like for it to go away - is it configurable somehow?
> (sorry if this was mentioned in the thread, I have only had time lately
> to skim through the lists - where does time go??). 
> 
> This is how it (does not) work(s) in my case (0.3.6):
> 
> - point to a non existing card on purpose so that jackd can't start
> - press "Start"
> - jackd does not start :-)
> - qjackctl pops up a window that says:
>   "Error: Jack Audio Connection Kit", etc, etc. 
> - click on "Cancel" (the only option it shows). 
> - click on "Setup" to fix the problem
> - qjackctl pops up the error window again before I'm done
> - it has _focus_ so I can't continue working on the "Setup" panel
> LABEL AGAIN:
> - click on "Cancel" again
> - keep working on "Setup"
> - if (managed to fix problem) GOTO FIXED
> LABEL WHAT?:
> - pop up window shows up again (I'm old and slow)
> - GOTO AGAIN
> 
> LABEL FIXED:
> - if (do nothing and wait a bit) GOTO WHAT?
> 
> - give up and press "Start", jackd starts fine. 
> 
> Not useful. Not even retrying once. I can't think of a situation where
> jackd fails to start on the first time and will on the second try a few
> seconds later. 
> 

oh my,

fwiw, the retry logic is there since dawn. i can assure you it's been
there for half a decade now ;) it's there for making sure qjackctl connects
to the starting jackd server as a client of its own.

indeed, this logic is some kind of a leftover from the early days. when
machines were slower (in errors per second:) and jackd had some
considerable startup overhead before stabilizing to accept client
connections.

the delay between retrials is/was even progressive ie. each retrial takes
a bit longer then the one before, but that's now irrelevant i'm afraid ;)

the retrial code path will be scrapped asap. the only way for you to avoid
qjackctl being stalled due to a (very) slow jackd startup is now giving it
a slack via the start delay configuration setting (cf Setup/Settings/Start
Delay).

cheers
-- 
rncbc aka Rui Nuno Capela
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] qjackctl & server name

[fons]

On Wed, Jun 16, 2010 at 12:00:50AM +0100, Rui Nuno Capela wrote:

> ok, will make it retry just once then.

Having to wait for that retry to fail (it will) 
is probably as irritating as it is now. 

See also Fernando's message - I can confirm this 100%.

What about a [Retry] [Cancel] choise in your
error box ?  Or just nothing, you can always
click [Start] again...

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