Re: [LAD] audio/midi app development

[James Morris]

On 18 June 2010 11:06, James Morris  wrote:
> On 15 June 2010 20:23, Harry Van Haaren  wrote:
>>
>> Hey James,
>>
>
> ...
>
>> Anyway, where can we find out more about your project? I'd have some MIDI / 
>> JACK MIDI gtk
>
>
> Ok I've got it on github now:
>
> http://github.com/jwm-art-net/BoxySeq
>
> i keep trying to add a new README.run file but it insists everything
> is up to date :/
>
> Basically, have gtk+jack installed, etc,etc.
>
> type 'make'
> type './boxyseq'
>
> do it in an 'xterm' so you can:
>
> resize the xterm to 128 x 128 minimum
> press and hold ctrl + right-mouse-button to select tiny font
>
> and hey presto, watch those little boxes get placed...
> and hey presto, watch them not get removed.
>
> and then think 'there's a project if ever i saw one that's never gonna
> get finished'

you may notice the display is a bit naughty, it reads directly from
the freespace_state array  - it should not do this, it won't, but it
does just for some visual satisfaction that it's actually doing
something.

> james.
___
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

[James Morris]

On 15 June 2010 20:23, Harry Van Haaren  wrote:
>
> Hey James,
>

...

> Anyway, where can we find out more about your project? I'd have some MIDI / 
> JACK MIDI gtk


Ok I've got it on github now:

http://github.com/jwm-art-net/BoxySeq

i keep trying to add a new README.run file but it insists everything
is up to date :/

Basically, have gtk+jack installed, etc,etc.

type 'make'
type './boxyseq'

do it in an 'xterm' so you can:

resize the xterm to 128 x 128 minimum
press and hold ctrl + right-mouse-button to select tiny font

and hey presto, watch those little boxes get placed...
and hey presto, watch them not get removed.

and then think 'there's a project if ever i saw one that's never gonna
get finished'


james.
___
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]

Gordon JC Pearce wrote:

On Thu, 2010-06-17 at 00:08 +0200, Ralf Mardorf wrote:

  
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.



Do it with Windows, or Mac OSX for that matter.  PC hardware (and Macs
really are just PCs, now) cannot - for some odd reason - keep time.

The 2MHz 6809 in my ESQ-1 is rock solid - absolutely dead even.  Same
with the 8MHz 68000 in an Atari ST; Cubase 3 is still my favourite
sequencer.  No "slop" at all.  Why can't a 3.4GHz Athlon get even close
to that?

Gordon MM0YEQ


The C64 had no jitter but it wasn't able to record real human touch. 
I've got an Atari ST with the latest Atari Cubase version, it's also 
without jitter and for most cases it has enough ticks.


Btw. I did run the EMC2 / HAL latency test and max jitter was < 8000 ns, 
so this latency test might show that some parts of my computer are ok. 
Kernel for the EMC2 live cd is a rtai patched one.


Joshua Boyd wrote:

On Thu, Jun 17, 2010 at 10:37:25AM -0400, Gene Heskett wrote:

  

At my school we transfered the CAD files per floppy to a DOS box that
controlled the CNC machine, guess that's for the same reason, bad rt
capabilities of newer OSes and machines.
  
The RTAI works pretty well, I can start a job, switch away from that window, 
and talk to the guys on IRC, or browse the web without hurting the job.  
That to me is true multitasking.



So, that leaves me wondering why no one seems to be trying RTAI for
audio work?  Or is someone doing that and I'm just not aware?


*?*

Cheers!

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

[Gordon JC Pearce]

On Thu, 2010-06-17 at 00:08 +0200, Ralf Mardorf wrote:

> 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.

Do it with Windows, or Mac OSX for that matter.  PC hardware (and Macs
really are just PCs, now) cannot - for some odd reason - keep time.

The 2MHz 6809 in my ESQ-1 is rock solid - absolutely dead even.  Same
with the 8MHz 68000 in an Atari ST; Cubase 3 is still my favourite
sequencer.  No "slop" at all.  Why can't a 3.4GHz Athlon get even close
to that?

Gordon MM0YEQ

___
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

[Joshua Boyd]

On Thu, Jun 17, 2010 at 10:37:25AM -0400, Gene Heskett wrote:

> >At my school we transfered the CAD files per floppy to a DOS box that
> >controlled the CNC machine, guess that's for the same reason, bad rt
> >capabilities of newer OSes and machines.
> 
> The RTAI works pretty well, I can start a job, switch away from that window, 
> and talk to the guys on IRC, or browse the web without hurting the job.  
> That to me is true multitasking.

So, that leaves me wondering why no one seems to be trying RTAI for
audio work?  Or is someone doing that and I'm just not aware?

___
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 Thursday 17 June 2010, Ralf Mardorf wrote:
>Philipp Überbacher wrote:
>> Excerpts from Gene Heskett's message of 2010-06-17 01:32:00 +0200:
>>> 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
>>> 
>>>
>>>
>>> --Top 100 things you don't want the sysadmin to say
>>
>> Thanks, I found it eventually (I'm really bad at using search engines).
>> Quite interesting, it uses a RTAI patched kernel. I also read this has a
>> module to disable SMIs, which is kind of hard to believe..
>>
>> At my school we transfered the CAD files per floppy to a DOS box that
>> controlled the CNC machine, guess that's for the same reason, bad rt
>> capabilities of newer OSes and machines.
>
>Never ever! I bet the DOS machine 'controls' micro controllers used by
>the CNC machine. Imagine a conical object where you wish to engrave a
>word in a reasonable time. Have fun using my computer + a Linux kernel
>rt (or any windows rt) to do this ;).

Chuckle.  We have SW that can take your name, wrap it around a beer can 
sized object, and once the code is correct, carve your name on that cylinder 
in maybe a minute.  That would take a machine setup with 4 axis control, 
which mine is.  And all 4 axis motors are controlled by step and direction 
controls over a single parport.  Using xylotex motor drivers.

-- 
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)
*** Knghtbrd is now known as SirKewLDooD
*** Mercury kicked SirKewlDooD from #quakeforge (*WHACK*)
___
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 Thursday 17 June 2010, Philipp Überbacher wrote:
>Excerpts from Gene Heskett's message of 2010-06-17 01:32:00 +0200:
>> 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
>> 
>
>Thanks, I found it eventually (I'm really bad at using search engines).
>Quite interesting, it uses a RTAI patched kernel. I also read this has a
>module to disable SMIs, which is kind of hard to believe..

Not sure about the SMI, but screen blanking has to be disabled, that bites 
in the the IRQ timing very badly.  So when I walk away, I need to remember 
to shut that old CRT Samsung off manually.

>At my school we transfered the CAD files per floppy to a DOS box that
>controlled the CNC machine, guess that's for the same reason, bad rt
>capabilities of newer OSes and machines.

The RTAI works pretty well, I can start a job, switch away from that window, 
and talk to the guys on IRC, or browse the web without hurting the job.  
That to me is true multitasking.


-- 
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)
"I'd love to go out with you, but I'm having all my plants neutered."
___
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 Thursday 17 June 2010, Ralf Mardorf wrote:
>> 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.

That, other than I have lived long enough to have been there and done that, 
hasn't a lot to do with it.  I have spent 75 years refusing to grow _up_. :)

-- 
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)
Any stone in your boot always migrates against the pressure gradient to
exactly the point of most pressure.
-- Milt Barber
___
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 Thursday 17 June 2010, Ralf Mardorf wrote:
>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, 

There are several boards about that will let you treat a stepper equipt 
machine like they were servo's.  But in either case, if the stepper misses a 
step, game over.  So one stays within the limits of what the stepper can do. 
I would explain why steppers and high speeds are mutually exclusive, but 
then I'd really be off topic.

>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 have one friend down in TX that is running his stepper mill with a TRS-80 
Color Computer whose clock is .79mhz.  He has been making steam engines with 
it.  Slowly, very slowly, using a Dremel for a spindle.  For that, Dremels 
area POS.

Midi's timing is fairly critical, but steppers are even fussier at higher 
speeds where the torque falls off.

>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?

A good question.  I believe the wiki may have a list of hardware broken down 
that way, but its nowhere near complete or definitive.  My machine is driven 
by an early athlon single core, running at 1.6Ghz.  That is why the latency-
test was written, beca

Re: [LAD] audio/midi app development

[James Morris]

All very fascinating I'm sure.
___
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]

Philipp Überbacher wrote:

At my school we transfered the CAD files per floppy to a DOS box that
controlled the CNC machine, guess that's for the same reason, bad rt
capabilities of newer OSes and machines.
  


PPS:

CNC machines are very expensive. Even if newer OSes and machines should 
be able to do valid real-time jobs, a school doesn't have the money to 
buy state-of-the-art CNC machines all the times. Brauner microphones was 
(maybe still is) using a DATRON CNC, this is a low-cost CNC machine and 
it is controlled by pics, just the CAD software is using DOS, but 
controlling those pic micro controllers.

___
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:

Philipp Überbacher wrote:

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

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



Thanks, I found it eventually (I'm really bad at using search engines).
Quite interesting, it uses a RTAI patched kernel. I also read this has a
module to disable SMIs, which is kind of hard to believe..

At my school we transfered the CAD files per floppy to a DOS box that
controlled the CNC machine, guess that's for the same reason, bad rt
capabilities of newer OSes and machines.
  


Never ever! I bet the DOS machine 'controls' micro controllers used by 
the CNC machine. Imagine a conical object where you wish to engrave a 
word in a reasonable time. Have fun using my computer + a Linux kernel 
rt (or any windows rt) to do this ;).


Pardon, you added old DOS machine ... no no, a 80286 + digital research 
DOS isn't able to do this kind of real-time too. I bet there are pics, 
DSPs or any other micro chips involved.


Regarding to MIDI, I will repair my ATARI ST, but I still belief that 
Linux is the right way for the future.

___
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]

Philipp Überbacher wrote:

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

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



Thanks, I found it eventually (I'm really bad at using search engines).
Quite interesting, it uses a RTAI patched kernel. I also read this has a
module to disable SMIs, which is kind of hard to believe..

At my school we transfered the CAD files per floppy to a DOS box that
controlled the CNC machine, guess that's for the same reason, bad rt
capabilities of newer OSes and machines.
  


Never ever! I bet the DOS machine 'controls' micro controllers used by 
the CNC machine. Imagine a conical object where you wish to engrave a 
word in a reasonable time. Have fun using my computer + a Linux kernel 
rt (or any windows rt) to do this ;).

___
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 01:32:00 +0200:
> 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

Thanks, I found it eventually (I'm really bad at using search engines).
Quite interesting, it uses a RTAI patched kernel. I also read this has a
module to disable SMIs, which is kind of hard to believe..

At my school we transfered the CAD files per floppy to a DOS box that
controlled the CNC machine, guess that's for the same reason, bad rt
capabilities of newer OSes and machines.
-- 
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

[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

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

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

[Tim E. Real]

On June 15, 2010 02:40:30 pm James Morris wrote:
> On 15 June 2010 16:55, 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. you need to mentally disconnect
> > what is going on in the backend from what is going on in the GUI : the
> > backend can tell some layer of code in the GUI what is happening, but
> > defer updates to a reasonable refresh rate.
>
> I do think I have mentally disconnected the backend and GUI sides of
> things. I mean, the backend (what I referred to as the engine) is
> working without any GUI to act as a crutch for it. Nor when the GUI is
> working will the backend (at least the Real Time thread) call any of
> the GUI code.
>
> But the refresh rate is a good point. I don't know how the stuff which
> appears and disappears faster than the refresh rate will be
> represented visually (some kind lightening fast image (anti-aliasing)
> filter?) - or (more likely) it won't be represented at all.
>
> Does anyone actually use MIDI (note) data beyond refresh-rate speeds!? :D

Perhaps more importantly, be able to detect the exact time the notes occurred 
 and be able to observe quick, short note or controller changes not visible by 
 your eyes.

If it is desired to visually observe events shorter than the screen refresh 
 rate can show,  how about a 'scope trace' or 'chart recorder' style box?
Say 100 horizontal pixel positions on the graph represents 1/60 second
 (the refresh rate of most LCDs).
Thus each pixel position represents 1/100 of 1/60 second.
The vertical graph positions represent some data, midi CC value for example.

Thus the entire graph box need only be updated every 1/60 second,
 or even less if say 200 pixels, representing 1/30 second, are used,
 and so on...

If a graph is not desirable, say a knob or slider control instead, 
 then another idea is to change the colour of the control
 indicating something quick happened, say for example a quick 
 change to a new value and then quickly back to the previous value,
 which your eyes, and monitor, would not have noticed.
It's an important change nonetheless, because your ears heard it.
Perhaps some meaning could be conveyed through the actual colour used.
Perhaps a digital number on the control face indicating how many events
 occurred. 
Although you might want to smooth this by only updating
 once per second for example.
The idea is to 'latch' detection of short events, for longer display later.
Because even if you had a monitor with a very high refresh rate,
 your eyes still aren't going to detect short events, so it's pointless
 to only display the event for just that brief period, no?
But with those methods, it's a question of how often you want the
 control's colour or number to change, or even if you want to
 manually 'reset' them after having been informed of the changes.

You could get fancy by making 3D controls, where the depth
 conveys some information.
Say a knob which is actually 100 knobs stacked depth-wise.
The 100 knobs represent all the changes during 1/60 second.
You could rotate the whole assembly to view it as a sort of 'graph',
 or rotate it 'normally' to just show the front knob representing the most
 recent value. 
OK, well that's a bit far fetched, but...

(Just a few ideas born while thinking of how to display live oscilloscope
 traces on an LCD monitor, so this discussion of displaying live data 
 on slow refresh devices interests me...)

Tim.

>
> >>I'm also wondering about
> >> going for an "Immediate Mode" GUI using SDL, possibly with OpenGL, I'm
> >> unsure... It's a way off yet, I'm concentrating on getting the engine
> >> working without a UI first.
> >
> > Gtk or Qt or whatever will work just as well in terms of screen
> > refresh/update as any other solution. That doesn't mean that there
> > might not be other reasons to prefer a solution.
>
> The program will be very visual (two dimensional). The idea is born
> from something which happens visually (placing things next to each
> other). It will need some kind of custom widget to display the main
> 'canvas'. Notes will essentially be represented as boxes within.  As
> they will persist after note-off, fading them out would be required.
> The boxes might look nicer with smooth corners ;-) Some boxes will
> need title bars, handles for moving, resizing, etc. Eg
> window-decorations. Transparency will also be very advantageous.
>
>

Re: [LAD] audio/midi app development

[Harry Van Haaren]

Hey,

I decided to throw up a github repo of my JACK MIDI stuff, (only one simple
(bad) app so far),
but I intend to improve it as I learn PThreads properly and things like
jack_ringbuffer.

http://github.com/harryhaaren/JACK-MIDI-Examples

My Gtkmm Widgets are zipped and on the way to you.

-Harry


WRT:

> Yes I'd be interested in taking a look at your demo widgets.
>
___
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

[James Morris]

On 15 June 2010 20:23, Harry Van Haaren  wrote:
> Hey James,
>
> Lots of idea's going around there anyways.. Thats great.
> Its been a while since I've been appealed by the "custom widget" craze,
> but you got me intrested enough to relpy...
>
> I quite like the way one can write custom widgets in GTK. It involves some
> small steps, but once you've got your head around them (maybe you already
> have)
> its quite fun.. :-)
>
> I've set up one folder in my programming dir call gtkmmWidgets, lots of
> small / medium sized
> widgets in there. Can throw it into a tarball and mail it to you if you
> like. Small Demos:
> Random Widgets
> (You may notice the "screenshot tear" in the "midi-editor"... to humans its
> not like that!
>
> Anyway, where can we find out more about your project? I'd have some MIDI /
> JACK MIDI gtk
> example code aswell if your intrested.. (cant garantee its all correct, but
> it works at least..)
>
> Cheers, -Harry
>

Hi Harry,

Yes I'd be interested in taking a look at your demo widgets. I've just
(finally!) found/looked for the src to Luppe and will have a look at
it.

The only information about my project is scattered around, random,
half-burried in off-topic ramblings.

boxyseq

Cheers.
James.
___
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]

Hey James,

Lots of idea's going around there anyways.. Thats great.
Its been a while since I've been appealed by the "custom widget" craze,
but you got me intrested enough to relpy...

I quite like the way one can write custom widgets in GTK. It involves some
small steps, but once you've got your head around them (maybe you already
have)
its quite fun.. :-)

I've set up one folder in my programming dir call gtkmmWidgets, lots of
small / medium sized
widgets in there. Can throw it into a tarball and mail it to you if you
like. Small Demos:
Random 
Widgets
(You may notice the "screenshot tear" in the "midi-editor"... to humans its
not like that!

Anyway, where can we find out more about your project? I'd have some MIDI /
JACK MIDI gtk
example code aswell if your intrested.. (cant garantee its all correct, but
it works at least..)

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

[James Morris]

On 15 June 2010 16:55, 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. you need to mentally disconnect
> what is going on in the backend from what is going on in the GUI : the
> backend can tell some layer of code in the GUI what is happening, but
> defer updates to a reasonable refresh rate.

I do think I have mentally disconnected the backend and GUI sides of
things. I mean, the backend (what I referred to as the engine) is
working without any GUI to act as a crutch for it. Nor when the GUI is
working will the backend (at least the Real Time thread) call any of
the GUI code.

But the refresh rate is a good point. I don't know how the stuff which
appears and disappears faster than the refresh rate will be
represented visually (some kind lightening fast image (anti-aliasing)
filter?) - or (more likely) it won't be represented at all.

Does anyone actually use MIDI (note) data beyond refresh-rate speeds!? :D

>>I'm also wondering about
>> going for an "Immediate Mode" GUI using SDL, possibly with OpenGL, I'm
>> unsure... It's a way off yet, I'm concentrating on getting the engine
>> working without a UI first.
>
> Gtk or Qt or whatever will work just as well in terms of screen
> refresh/update as any other solution. That doesn't mean that there
> might not be other reasons to prefer a solution.

The program will be very visual (two dimensional). The idea is born
from something which happens visually (placing things next to each
other). It will need some kind of custom widget to display the main
'canvas'. Notes will essentially be represented as boxes within.  As
they will persist after note-off, fading them out would be required.
The boxes might look nicer with smooth corners ;-) Some boxes will
need title bars, handles for moving, resizing, etc. Eg
window-decorations. Transparency will also be very advantageous.

That's why I was thinking of something like SDL.

James.

> --p
>
___
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 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. you need to mentally disconnect
what is going on in the backend from what is going on in the GUI : the
backend can tell some layer of code in the GUI what is happening, but
defer updates to a reasonable refresh rate.

>I'm also wondering about
> going for an "Immediate Mode" GUI using SDL, possibly with OpenGL, I'm
> unsure... It's a way off yet, I'm concentrating on getting the engine
> working without a UI first.

Gtk or Qt or whatever will work just as well in terms of screen
refresh/update as any other solution. That doesn't mean that there
might not be other reasons to prefer a solution.

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