You mean you can connect seq24's midi ports using qjackctl?! That doesn't work on the latest Agnula/DeMuDi. Or does seq24 talk to Jack in some other way? I'm enjoying the .oggs too. What part of the system did the drums?

Oh - that was the bit I didn't know about. Thanks!

On Friday 13 May 2005 18:28, Jens M Andreasen wrote: I've started to use Zyn now too :) Under mdk 10.2. I think it works, though they haven't packaged the instruments, which is a shame. What is it exactly that you don't get to work? -- http://spamatica.se/musicsite/

On Fri, 2005-05-13 at 21:02 +0200, Jens M Andreasen wrote: They are back (kind of.) Now I get this everytime I hit the virtual keyboard in zyn: **** alsa_pcm: xrun of at least 1.364 msecs delay of 802.000 usecs exceeds estimated spare time of 684.00 restart ... delay of 802.000 usecs exceeds estimated spare time of 684.000; restart ... delay of 703.000 usecs ... ... And no, it is not like I can hear anything. Not notes, not noise, no nada. -- ( ) c[] // Jens M Andreasen

On Fri, 2005-05-13 at 15:46 -0400, Paul Davis wrote: Uhmm, the demo samples at Pauls site made me think that Zyn is the perfect mate for a layer with my own polysynth (Mx44.) I have this theory that one should mix and match to approach an original personal sound. I am looking forward for the day when Zyn is up to low latency real-time. Oh well. Yours ... -- ( ) c[] // Jens M Andreasen

On Fri, 13 May 2005 17:02:42 -0400 Lee Revell <rlrevell(a)joe-job.com> wrote: I beg to differ. Especially because some AD/DA's introduce quite a bit of additional latency. When i used my cs46xx based card i had to go down to 32 frames to get an acceptable latency for playing my guitar through jack-rack. I once measured the roundtrip latency of this card and found out my AD/DA's added another 4-5ms of latency to the 1.333ms latency which were caused by the periodsize of 32 frames. And it seems 6ms total latency was fine for me :) Flo -- Palimm Palimm! http://affenbande.org/~tapas/

Florian's pratical experience confirms what I stated in my other message. My take on the matter is to get a good soundcard with fast DAC/ADC ( 2msec round trip AFAIK) and use something like 64frames latency. 64 frames gives you still good,reliable RT performance and does not push the kernel to the limits nor does the setup part of DSP of dsp algorithms get bigger than the actual audio rendering. eg in a sampler you don't have only to render the audio samples but check for note events, ramping, calculate filter coefficients etc which all take some time which could be bigger than rendering the audio of N samples for N a very small number (eg N < 4). cheers, Benno http://www.linuxsampler.org Florian Schmidt wrote:

On Sat, 2005-05-14 at 08:45 +0200, Jens M Andreasen wrote: Clarificaton: The good people across the street at Clavia, who actually do commercial synthesizers, considers anything but "now" to be slowish. Their sense of "now" is somewhat below 0.3ms Untill we get hardware keyboards that measures the impact at rock-bottom (like a clavinet), there will always be an oily slur between the player and the loudspeakers. Having the trigger point in mid-space (as for contemporary keyboards) isn't excactly helpful, and this is also where I get the 0.3ms approximation from. It simply ain't worth it to go below that point. (yet ...) -- ( ) c[] // Jens M Andreasen

Since we cannot increase the speed at which the sound travels and even DACs add some latency (1msec or so) I see any effort to reduce latency below 2-3msec quite useless. We know that halving the number of frames (soundcard period size) we run the audio software at is doubling the IRQ rate and you can quickly achieve a point where a significative chunk of CPU is burnt in the IRQ handlers. It could change if CPU get considerably faster but then you begin to hit other limits, eg the PCI DMA minimum transfer sizes which limits your minimum soundcard period size. Plus what happens if your speakers are 1m away from the listener ? Another 3msecs added to the total "latency between hitting a key and hearing the sound". If you move the speakers another 50cm away from the ear ? Another 1.5msecs delay get added. Humans are more sensitive to differences than to absolute values. Eg in physics you feel the acceleration but not the speed. So if you take into consideration the real latency between hitting a key and hearing the sound it's made up of several components. You could try to do a test, compare the latency you feel between having the speakers at 1m and 1.5m away from your ears (blind A/B test). I guess it's not that easy to figure it out. Plus if you are playing a blazing fast hardware synth over a midi master keyboard we know midi adds 1.1msec per note-on command. If you play an eg 8 finger chord, assuming you hit all keys the very same moment, the chord is spread over an interval of 8.8msecs and the 8th key starts to sound 7.7msec after the 1st key. Yet the whole world is using MIDI keyboards all over the place. I heard Peter Gabriel uses a Powerbook with a multi GB sample (PMI postpiano) that is streamed from disk, it uses the NI Kontakt player and it cannot certainly achieve unreasonably latencies (I think Mac users usually get good performance at 3-6msecs). I've read a real piano has some latency too (AFAIK in the range of a few msecs) so they are already "used" to latency. Organ players too. I think the idea of achieving 0msec latency is simply crazy and a waste of resources, every natural instrument has a builtin latency and it's certainly not in the usec range. Humans are more sensitive to jitter but jitter can be minimized using MIDI timestamping and higher priority midi sensor threads so it's not an issue in PC based synths/samplers. Plus due to the nature of the sound, low frequency oscillations take longer to get recognized since in theory you need to hear a full cycle of the wave to "measure" the frequency. at 100 Hz it means 10msec ... an eternity for your standards :) Of course some instrument players, especially those that play percussive sounds are more sensitive than others, but the question is how small is this time ? Is there scientific data around that can state: "if latency of the virtual percussion instrument is higher then X then the instrument is unusable for 30% of professional musicians" ? Take a drummer: that's the distance between the human and the pads ? up to 70cm ? time between "pad triggered to drummer hearing the sound" = ? 2msecs of air travel + time to to excite the pad. I'm not an expert in the field but I assume that if you hit a pad with the stick the pad first goes down, then the elasticity of the pad comes into play , absorb the kintetic energy of the stick, which is bounced back and at this point the drumpad starts vibrating (albeit for only a short time). Of course you hear the first half cycle too, when you push the drumpad down with the stick, but the question is what's the time it takes for the drumpad to bounce the stick back and start sounding ? It would be interesting if someone that knows more on the matter (eg measuring the latency sensitivity of drummers) could give us his opinion on the matter. cheers, Benno http://www.linuxsampler.org Jens M Andreasen wrote:

On Sat, May 14, 2005 at 12:48:34PM +0200, Jens M Andreasen wrote: It's rarely done these days, but in the 19th century it was quite normal for a symphonic orchestra to play without a conductor. That's the origin of the title 'concert master' for the first violin player. But of course you don't do Mahler's 8th that way. True. By no means :-) Down with the privileges of clavinet players ! :-) -- FA

On Sat, May 14, 2005 at 02:29:54PM +0200, Jens M Andreasen wrote: Sounds scary enough... wouldn't have liked to be in your place ! You wouldn't have a recording of that truly unique concert ? ;-) Regards, -- FA

On Thu, May 19, 2005 at 12:01:02AM +0200, Jens M Andreasen wrote: Yes, but the violins are not playing all the time, and anyway the bow strokes are determined by musical phrasing and not by meter. Such a performance without a conductor is possible only if the piece has been rehearsed before with a conductor, and everybody has agreed on interpretation, tempo changes, etc. Don't suggest that to a concert master - they tend to be sensitive ;-) -- FA

[Jens M Andreasen] Trading jitter for constant latency can work well for some, too. Unfortunately the increasingly popular MIDI over USB connections already introduce a millisecond of jitter, so if you're already working at a blocksize of 64 at 44.1 or faster it's not worth the effort. Cheers, Tim

On Thu, 19 May 2005 14:14:06 +0200 Jens M Andreasen &lt;jens.andreasen(a)chello.se&gt; wrote: Hi, interesting enough, in a 2 periods/buffer setup a synthsist will have to bear the exact same latency if he wants constant latency. If you give up constant latency you wil get quicker response. Here's the rolled out example: Interrupt N happens at time t_n The soft synth application prepares the playback buffer for period N+1 (the time after Interrupt N+1 up to the time of Interrupt N+2) sometimes before interrupt N+1 the keyboarder hits a note (at time t_n + delta). Now, maybe the soft synth already is done preparing the buffer for Period N+1, or it might be right in the middle of doing so. Thus, there's no reliable way to put the corresponding audio event intot the buffer for period N+1. So, what the soft synth must do is schedule the event for period N+2. Interrupt N+1 happens (at time t_n+1) The softsynth produces output for period N+2. Now it can put the sound corresponding to t_n + delta at the right position of the buffer which will be audible during period N+2. Interrupt N+2 happens (at time t_n+2) At t_n+2 + delta the sound corresponding to the key hit at time t_n + delta will be audible. .. I don't know of any _reliable_ constant delay (jitter free) way to schedule events happening during period N for playback during period N+1. If anyone does, please enlighten me. Conclusion: In a typical 2 periods per buffer setup a softsynth player and a guitar player using the computer as efx rack will experience the exact same delay. Flo -- Palimm Palimm! http://affenbande.org/~tapas/

On Thu, 19 May 2005 16:41:13 +0200 Alfons Adriaensen &lt;fons.adriaensen(a)alcatel.be&gt; wrote: Assuming though that the softsynth conforms to jack RT constraints it needs to finish process() as fast as possible. Let's assume a very leightweight synth which takes a time t_process which is much smaller than the time available for a single period to process the data. To make it clear: Interrupt N happens softsynth's process() is called (we assume it's the only jack client, so it's called right after the Interrupt happens). It finishes in t_process seconds (<< t_(n+1) - t_n) Thus there's for all practical purposes still t_(n+1) - t_n seconds left of period N. Any event that happens after t_n + t_process _cannot_ be scheduled for period N+1 as the processing for period N+1 is already done. Graphically (use fixed size font): t -----> |Irq N |Irq N+1 |Irq N+2 ||process_n() ||process_n+1() | | |process_n() done | |process_n+1() done | | |keypress | | The keypress cannot be scheduled for period N+1 (with constant delay) as the process_n() (which prepared the buffer that will be audible during period N+1) is already done. It can be put into the buffer by process_n+1(). This buffer will be audible after Irq N+2 This breaks afaics the rule of _reliably_ constant delay. OTOH i don't qute grok it. Care to roll it out? Flo -- Palimm Palimm! http://affenbande.org/~tapas/

On Thu, 19 May 2005 17:40:41 +0200 Alfons Adriaensen &lt;fons.adriaensen(a)alcatel.be&gt; wrote: Of course. I assumed that you assumed that i know this :) But this is not the problem. I still insist: To get constant latency you have to take 2 periods worth latency into account. I cannot spell it out more clearly than i have done. Exactly. Flo -- Palimm Palimm! http://affenbande.org/~tapas/

On Thu, May 19, 2005 at 06:11:29PM +0200, Ralf Beck wrote: You're missing some of the details. All events have one period added to their timestamp, so the events received in cycle N will be processed by the process routine in cycle N+1. -- FA

On Thu, May 19, 2005 at 05:59:25PM +0200, Florian Schmidt wrote: The scheme I described will give you exactly 2 periods latency. cycle N N+1 N+2 N+3 ------|ppp------------E---|ppp----------------|ppp------------S---|ppp--- | ^ | | ^ | frame k k+i k+n k+2n k+2n+i k+3n ppp = jack_process() running n = period size Consider the event E. Its frame_time is k+i, we add n to get k+n+i, and put this into the queue read by jack_process(). In cycle N+1, jack_process() calculates the offset for the events it finds in the queue. For E, it will find offs = k+n+i - k+n = i, and offs < n, so it will put the audio signal corresponding to E starting at sample i in the current period. That sample has a latency w.r.t. the start of the current period of n+i, so we will hear the event at the place marked S, exactly two periods after E. The latency of two periods is composed of one period from the hardware,and one period we added to the timestamp of the event. -- FA

Uhmm .. What did I say? Well, yes ... I said: Deafness! Why now? Because one of my closest friend can't hide his handicap anymore. Because in todays entertainment environment we are all affected. I am a musician. Am I affected? Most probably, yes. If you have had temporary problems with Tinitus, then again yes. What is Tinitus? Tinitus is a satanic noise unrelated to your environment, emerging out of clear blue sky, reminiscent of those 50s tapes of electronic music you always hated. How do I aquire Tinitus? Wrong question! How do I avoid to aquire Tinitus? Use ear protection. Never trust your manager should he say you are better looking without them. Use common sense as in: Oh my goodness!? Isn't this insanely loud? .... hello? Take care of the volume in your walkman/ipod. What are the consquences of Tinitus? You will become Beethoven, but not nescessarily with his compositional skills. Was that supposed to be funny? Nope! Is it so that you yourself is becoming deaf? What??

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 14 May 2005 13:45, Fons Adriaensen wrote: People will use visual feedback to sync to that guy, probably. :-) - - Burkhard - -- Libre Audio, Libre Video, Libre Software: www.AGNULA.org Public key available here: <http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&search=0xFD82303B> key FP 0A65 5E83 F44F 47A5 3DFC 19C5 7779 E411 FD82 303B

Hi, On Saturday 14 May 2005 12:57, Fons Adriaensen wrote: No, generally you feel the changing of the impuls which is also true while moving with only little less than light speed. And as you can`t determine the "real" absolute speed you have to assume that all of us are moving with ~c... ;-) (\me studying physics) But with not to long latencies you can compensate that. I remember doing a powerpoint-presentation once where the slide-changes had to come on-beat of the music while not being synchronised with midi etc. After the first tests I actually recognised the latency of evil MS and compensated it with clicking the button earlier... As far as my knowledge goes: more than 20ms are only usable for slow strings/pads... Arnold -- There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened. -- Douglas Adams, The Restaurant at the End of the Universe

On Sat, May 14, 2005 at 11:58:45AM +0200, Benno Senoner wrote: I beg your pardon? You say that you can "hear the first half cycle", but that the stick still has to be bounced away before the drumpad will "start sounding"? Do you mean that this first thing you hear is not a sound? If the (surface of) the drumpad moves, it produces a sound. Even if the stick is still touching it. Asbjørn