Re: [LAD] Impro-Visor created on sourceforge

[Ralf Mardorf]

drew Roberts wrote:
> I find we (people) often miss key points unless they are specifically pointed 
> out. Just trying to do my bit to see that we are actually understanding one 
> another so we can see what real disagreements remain. I find we (people 
> again) often think they disagree on more than they actually do due to 
> misunderstandings. Or they agree on some things they think they disagree on  
> and disagree on some things they think they agree on.
>   

My comment: :)

And in addition: Talking to each other often causes less 
misunderstandings than writing.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Ralf Mardorf]

Arnold Krille wrote:
> On Sunday 09 August 2009 14:12:56 Kjetil S. Matheussen wrote:
>   
>> No, as I said, the solution is very simple: Don't install a 64 bit OS.
>> That's what's causing your problems, apparently.
>> 
>
> Helloo! Please leave the 20th century where it belongs. Nowadays 64bit are 
> normal with new computers and its a terrible waste not to use them (reminds 
> me 
> of "640kB should be enough for everybody").
>
> If the combination of 64bit and 32bit-binary-only apps is broken, its the 
> developers or the distributions task to fix it. And the users task to point 
> out 
> the problems and demand the fix.
>
> Looking away by only using 32bits is _not_ the solution. And please stop 
> telling that "solution" to other people. We are in the 21th century after 
> all...
>
> Arnold

Wow :)

full ACK. Even if I prefer Debian based distros, I mentioned that Suse 
is a little bit smarter, e.g. the proprietary LightScribe 32-bit stuff 
can be installed to Suse 64-bit, but not to Debian 64-bit.

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

Re: [LAD] FLTK vs GTKmm

[Ralf Mardorf]

David Robillard wrote:
>> using your desktop theme which might be bad, too.
>> 
>
> Ick!  Using the desktop theme is not bad!  The user chose it for a
> reason!
>
> Less atrocious and weird looking "skinned" UI's designed by seemingly
> half-blind artistically retarded programmers, please :)
>
> -dr (half-blind artistically retarded programmer who at least knows it)

:D

On the other hand neither GNOME nor KDE are usable with dark themes, 
without causing some trouble, that's why I now use bright seems again. 
Non-graphic-design-retarded coders maybe want to design a relative 
neutral GUI, that still fit to most desktop themes.

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

Re: [LAD] FLTK vs GTKmm

[Ralf Mardorf]

Jens M Andreasen wrote:
> Really, an Atari ST is more responsive.

For me TOS is still the best OS for MIDI usage with external MIDI 
equipment, but this isn't true, the Atari ST's response is very good 
when using a Blitter, but very bad when not using a Blitter.

For Linux I noticed, that when running into trouble because of 
resources, ION2 is a very good WM, but sometimes ION2 has got troubles 
because of some windows behaviour. I can't remember the applicatuions, 
but if I would be a coder for Linux, I would take care about WMs that 
are frame based, without any DE.

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

Re: [LAD] linux audio standards base?

[Ralf Mardorf]

*???* Pulseaudio, 64-bit and JACK are a strange issue. I'm using 64-bit, 
the proprietary flash for 64-bit and I can run JACK, use audio software, 
e.g. Qtractor and at the same time watch YouTube etc.. Pulseaudio is not 
installed. Am I missing something, because I don't have Pulseaudio?

Ralf

Patrick Shirkey wrote:
>
> On 08/11/2009 08:59 AM, Nick Copeland wrote:
>> The following is all opinion which I think is what was requested:
>>
>> > Here's an updated list of the possible official recommendations for 
>> discussion:
>>
>> We should not really be recommending anything and 'official' makes it 
>> sound rather orchestrated. We should be selling the benefits of the 
>> solution. If any attempt is made to mandate then we are going to run 
>> into reasonable resistance from both the apps and platform to any 
>> change as what is being proposed here increases compexity and 
>> abstraction of the audio interface which in anybodies book is a bad 
>> thing.
>
>
>
> Ok, so from what you are saying there is nothing particularly wrong 
> that the recommendations below would solve for a large enough number 
> of people as to make it worth suggesting any of them at all? I don't 
> think that I need to justify why the recommendations are offered but 
> if they are really not to be considered necessary then that is a 
> different story.
>
> The list below is simply attempting to solve as elegantly as possible 
> the real usability issues that currently crop up for a "normal" user 
> experience on 64 bit with the additional suggestion for the kernel 
> config as people were wondering how to get extended memory on a 32 bit 
> platform. I'm not sure if that last one is relevant myself but it was 
> suggested so it's on the list of suggestions to be considered.
>
>
>
> Here's an additional possible recommendation that occurred to me last 
> night.
>
> - If using skype consider purchasing a usb phone and using that as the 
> audio interface instead of relying on the onboard sound device as it 
> will probably make your life easier.
>
>
>
>
>
> Patrick Shirkey
> Boost Hardware Ltd
>
>
>
>
>>
>> - A distribution should attempt to run jack as the default audio 
>> server and should attempt to make the process pf starting jack easy 
>> for a non technical user.
>>
>> Why should a distribution do this? There are lots of reasons why they 
>> shouldn't.
>>
>> - Pulseaudio should attempt to connect to jack by default and fall 
>> back to the alsa layer if jack is not running.
>>
>> Why should pulse audio do this? There are lots of reasons why it 
>> shouldn't.
>>
>> - Closed source binaries such as those provided by companies like 
>> Adobe, Skype and Real Networks should provide flexibility for 
>> changing the audio library path and not be hardcoded to /usr/lib/
>>
>> Why should they do this? Skype has 400M users, Adobe at least double 
>> that. Why should they make consideration for perhaps a small number 
>> of hundreds of users: those that want Linux, and Audio, and 64bit? 
>> You are welcome to change the figure of 'hundreds' into 'thousands' 
>> but nowhere on earth does it reach anything like the number of Skype 
>> users on 'another' platform. What are we offering Skype by way of a 
>> carrot to make them even consider this? You have to put the request 
>> into the perspective of it just being yet another request made of 
>> them and all of the other requests leading to potential financial 
>> benefits to their organisation. All Linux can offer Skype is a number 
>> of paying subscribers, and those that fit this specific demand are 
>> very small.
>>
>> - For 32 Bit systems with memory of more than 8GB we recommend 
>> enabling CONFIG_X86_PAE in the kerneld
>>
>> The limit is theoretically 4G. Its a lot lower on pretty much all 
>> motherboards. If we put in any demands like this one it will sound 
>> like we have no idea about what we are talking about.
>>
>> - For a 64 bit desktop system please ensure the 32 bit libraries for 
>> alsa, jack and pulseaudio are installed by default.
>>
>> Is this relevant? Are you asking for just the 32 bit libraries? Both 
>> of them?
>>
>>
>> If somebody put this proposal in front of me, personally, I would not 
>> give it the time of day. There is no justification, no benefit being 
>> offered, and no real necessity to do it. There is nothing compelling.
>>
>> Nick.
>> Again, this was all opinion. The goal is a good one, the means don't 
>> quite seem to rise up to it.
>>
>> 
>> Share your memories online with anyone you want anyone you want. 
>> 
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] FLTK vs GTKmm

[Ralf Mardorf]

Patrick Shirkey wrote:
> Isn't this Sergey's Law?
>
> i.e.  The faster the hardware becomes, the slower the software 
> performs...
>
> I think he has tried to start a movement against this unwritten law of 
> computing. I can't recall the name right now though.

Software needed less resources in the 80ies, when we programmed in 
Assembler, but in the 80ies it was easy to keep track of things while 
programming for Z80, 6502, 6510 and 68000. I guess you Linux guys need 
to use C, because the CPUs and kernels have become much more complex.

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

Re: [LAD] FLTK vs GTKmm

[Ralf Mardorf]

Vincent Torri wrote:
>
>
> On Tue, 11 Aug 2009, Ralf Mardorf wrote:
>
>> For me TOS is still the best OS for MIDI usage with external MIDI
>> equipment, but this isn't true, the Atari ST's response is very good
>> when using a Blitter, but very bad when not using a Blitter.
>>
>> For Linux I noticed, that when running into trouble because of
>> resources, ION2 is a very good WM, but sometimes ION2 has got troubles
>> because of some windows behaviour. I can't remember the applicatuions,
>> but if I would be a coder for Linux, I would take care about WMs that
>> are frame based, without any DE.
>
> Did you try Enlightenment 0.17 ? In addition, it is based on a 
> powerful set of libraries that can be used to create beautiful 
> applications. Here is a program that uses these libraries (media player):
>
> http://www.calaos.fr/pub/video/calaos_media_music.ogg
>
> regards
>
> Vincent Torri

E17 looks well, but when I used it a long time ago on another machine it 
was disgusting experimental ;).

I can't play the OGG? Are you sure that it isn't broken?

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

Re: [LAD] FLTK vs GTKmm

[Ralf Mardorf]

Vincent Torri wrote:
>>
>> E17 looks well, but when I used it a long time ago on another machine 
>> it was disgusting experimental ;).
>
> well, we work hard for a release, so a lot of things has been fixed / 
> stabilized. Maybe you can try it again.

I'll try it again.

>> I can't play the OGG? Are you sure that it isn't broken?
> [snip]

I'm short of time now. It shouldn't be a problem because of the codes :S.

Ralf

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

Re: [LAD] [ANN] Invada Studio LV2 Plugins 1.2.0

[Ralf Mardorf]

VU meter: Maybe you should call it 'analogVUemu'.

Phase correlator: Yep, some people generally spilt frequencies at around 
200, resp. 250 Hz before they add effects or they avoid to panorama deep 
sounds. A phase correlator can be mistaken, because of some single 
sounds that don't matter in the sum. I just check my mixes by listening 
to them in mono, but I agree that some people don't hear phases and they 
become trouble, because their tapes are forbidden to be played on the air.

I didn't test your plugins and I don't believe in meters and phase 
correlators. I guess your VU meter is useless, but the phase correlator 
seems to be useful, the way both are described by you.

Explanation:

- Bad! Having a VU meter that can be adjusted to allegedly be in sync 
with some analogue VU meter never ever will be fine. Compare margin for 
your digital meters and the meters on your mixing console by playing the 
same song several times, they always will differ a little bit different, 
each time you play the song.
It seems to be dangerous to have such a VU meter, similar to microphones 
with switches at the handle, a stupid idea that can cause a lot of trouble.

- Okay! Broadcasting laws force to stick to limits for phase correlation 
and referring to your description it will be possible to see it by your 
phase meter.

My 2 cents to the theory of your meters.

Cheers,
Ralf

Fraser wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Fons
>
> Fons Adriaensen wrote:
>   
>> What's the point of using a meter if you adjust it to the signal ?
>> 
>
> You are not changing the signal, you are changing the amount of headroom the 
> VU
> meter has. http://www.reference.com/browse/wiki/Headroom
>
> To put it simply, 0dB on analogue equipment is indicating the optimal level.
> There is an amount of headroom above that level before distortion will occur.
>
> In the digital domain 0dB is the absolute maximum level and distortion occurs 
> at
> this point..
>
> So whenever analogue equipment needs to work with digital equipment it is
> configured so that 0dB in the analogue domain is at some (hopefully calibrated
> and consistent) level below 0dB in the digital domain. The actual value is
> arbitrary and depends part on preference and part on the quality of your
> analogue gear. So if you elect to have 9dB of headroom on you analogue gear,
> then you'd select -9dB on the plugin, and then VU metering 0dB will have the
> peak metering -9dB.
> - -18 to -9 is common, but I've seen all sorts of things.
>
>   
>> Anyway the meter plugin freezes my machine if the signal is muted
>> or removed. Probably due to denormals.
>> 
>
> I can't reproduce that.
> A clue may help. (distro, arch, kernel, soundcard, host etc).
>
> The plugins have been built on ubuntu studio (hardy) x64
> and tested on ubuntu jaunty (x64), Arch linux (x64) & AV linux (x32).
>
>   
>> The VU is not a VU,
>> 
>
> Correct since this plugin isn't in the analogue domain. It's a simulant.
> It does convey the 'perceived volume' of a signal better than a peak meter and
> does help if you are mixing to tape.
>
>   
>> the spectrum doesn't use valid 1/3 octave filters by any standard, 
>> 
>
> please advise where this standard is.
> AFAIK there are just algorithms that simulate the behaviour of electronic RC
> circuits with varying degrees of success, and yes I have a munge. Sorry if it
> disturbs you.
>
>   
>> and the phase meter doesn't indicate anything useful.
>> 
>
> Apart from the relative phase difference between the left and right channels.
>
> With the demise of vinyl the importance of phase has been lost too to some
> extent so it doesn't surprise me you don't what this meter is for or what it's
> trying to tell you.
>
> On vinyl out of phase signals make the needle go up and down instead of side 
> to
> side, this makes the needle bounce out of the groove. Worse still is what
> happens when you have low frequency out of phase sounds. The wave length (on 
> the
> vinyl) is large enough for the cutter to go through the vinyl... => This is 
> why
> everything below 200Hz is mono'd for vinyl during mastering in case you were
> wondering.
>
> A quick guide to interpreting the phase meter:
> * A mix that never goes +/- 20 is too mono. Pan something. Create some space
> with reverb. etc
> * A mix that spends all it's time between +/- 45 is as 'wide' as you want to
> get. You should able to see some variety in there of course, ie a verse and a
> chorus should be different widths.
> * If the phase meter spends any time over +/- 55 then audible cancellation 
> will
> occur if the mix is mono'd or listened to from a distance.
> * Any travel over +/- 60 is trouble, there is something out of phase in the 
> mix.
> although this may sound great with your head between the speakers it's going 
> to
> suck when heard anywhere else.
> * If the meters stays at +/- 90 then the whole mix is out of phase :)
>
> regards,
> Fraser
>
> -BEGIN PGP SIG

Re: [LAD] [ANN] Invada Studio LV2 Plugins 1.2.0

[Ralf Mardorf]

Dan Mills wrote:
> On Sun, 2009-08-23 at 18:26 +0200, Ralf Mardorf wrote:
>
>   
>> - Bad! Having a VU meter that can be adjusted to allegedly be in sync 
>> with some analogue VU meter never ever will be fine. Compare margin for 
>> your digital meters and the meters on your mixing console by playing the 
>> same song several times, they always will differ a little bit different, 
>> each time you play the song.
>> 
>
> Of course they read different things! They are measuring different
> things! 
>
> The VU is a slow response meter (300ms integration time IIRC)intended to
> (badly) track perceived volume, the meters on (most) DAWs are closer to
> digital peak meters intended to monitor absolute peak levels. Both are
> useful and both have a place. 
>
> The differences each time you play are why we leave the thick end of
> 20db of headroom between 0 VU and 0dbFS, you should (in a production
> environment) never be going anywhere near 0dbFS (there is no need for it
> in the age of 20+ bit ADC noise floors). 
>
>   
>> It seems to be dangerous to have such a VU meter. 
>> 
>
> Why is it dangerous? it tells you something about RMS levels which you
> would not otherwise know (peak reading meters provide little guidance as
> to perceived volume). 
>
> Now, I don't know about this particular implementation (I don't have an
> LV2  host to hand), but a good implementation of a VU would not be an
> inherently bad thing to have available. 
>
> Regards, Dan.
>   

If I understand correctly this VU meter can be adjusted. Someone might 
adjust it and than (s)he thinks it gives information about peak on his 
analogue mastering tape recorder, but it won't do this.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [ANN] Invada Studio LV2 Plugins 1.2.0

[Ralf Mardorf]

Fraser wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Adrian,
>
> Adrian Knoth wrote:
>   
>> Just a note: I personally don't like VUs in the digital domain.
>> 
> agree, their primary purpose is a bit meaningless.
>
>
>   
>> I prefer Bob Katz' K metering system (K12, K14, K20) with well defined
>> headrooms.
>>
>> Check out this page for a detailed description on the K metering system:
>>
>>http://www.digido.com/level-practices-part-2-includes-the-k-system.html
>>
>>
>> Note that many commercial software vendors ship analyzer plugins using
>> the K system, i.e. RME's DigiCheck.
>>
>> I'd suggest to go for this, too.
>> 
>
> thanks for the link, I wasn't aware of that before. I'll have a look at
> implementing it.
>
> cheers,
> Fraser

This are recording techniques. You shouldn't apply them by any function 
to adjust the meter to any imaginary point. The only useful thing is to 
have a pre-adjusted meter, that can't be readjusted by the audio 
engineer. For people who like Katz's technique, some marks might be 
useful and/ or a function that shows the most low and the most loud 
level. There might be other rules of thumb, not only Katze's. Meters are 
used to adjust signals. I understand what you aim at, I also understand 
what switches on mics, to turn them on and of are designed to, but there 
are good reasons why such things shouldn't be done.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [ANN] Invada Studio LV2 Plugins 1.2.0

[Ralf Mardorf]

Dan Mills wrote:
> On Sun, 2009-08-23 at 19:24 +0200, Ralf Mardorf wrote:
>   
>>  The only useful thing is to 
>> have a pre-adjusted meter, that can't be readjusted by the audio 
>> engineer. 
>> 
>
> How do you deal with the annoying detail that there are at least 3
> standard alignments between 0Vu and 0dbFs (EBU, SMPTE and US Radio)? You
> need a calibration tweak to allow you to set the meters to whatever
> standard the rest of your system is aligned to. 
>
> Regards, Dan.

I'm very sceptic that meters for studios in the box are in sync with 
external equipment. I'm also very sceptic about the quality of measure 
accurately for external equipment in any home recording studio, any 
semi-pro studio and even some pro studios, were the equipment isn't 
checked on a daily basis. Absolute accuracy becomes important especially 
if tapes are sent from one studio to the other. The effective value is 
sine wave +3dB = 0 and nothing else. Am I wrong?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[LAD] [Fwd: Re: [ANN] Invada Studio LV2 Plugins 1.2.0]

[Ralf Mardorf]

PS:

The effective value is sine wave +3dB = 0 and nothing else. Am I wrong? *Just 
for dBFS*

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

Re: [LAD] [ANN] Invada Studio LV2 Plugins 1.2.0

[Ralf Mardorf]

TU Berlin: "Lediglich bei den Rundfunkanstalten besteht wegen des 
Austauschs von Programmmaterial
auch über die Landesgrenzen hinweg die Notwendigkeit von einheitlichen 
Richtlinien. Da-
bei gilt in Europa ein Übernahmepegel von +18 dBu für 0 dBFS (EBU R68), 
in den USA
+24 dBu (SMPTE RP155)."

On English, for international broadcasting you need different 
adjustments. But then it's important that the meter is informed about 
the analogue mixer of the sound card too ;). I guess it will become 
nearly impossible to fit a dBFS RMS meter to any VU meter outside the 
studio in the box. An external VU meter can't be replaced by one in the 
box for Linux using different sound cards.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [ANN] Invada Studio LV2 Plugins 1.2.0

[Ralf Mardorf]

Dan Mills wrote:
> The key is that every stage has to have a known calibration, which is
> actually fairly common with professional cards.

Okay :) I don't know professional cards for home recording myself and 
the professional studios I know have external VU meters. For my Envy24 
based sound card I guess the converters aren't accurate, but even with 
this I might be wrong.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [ANN] Invada Studio LV2 Plugins 1.2.0

[Ralf Mardorf]

I wrote:
> Dan Mills wrote:
>   
>> The key is that every stage has to have a known calibration, which is
>> actually fairly common with professional cards.
>> 
>
> Okay :) I don't know professional cards for home recording myself and 
> the professional studios I know have external VU meters. For my Envy24 
> based sound card I guess the converters aren't accurate, but even with 
> this I might be wrong.

Pardon, the converters might be fine ;). The stages behind/ before the 
converters, the amps, might have too much tolerance to realise a VU 
meter that is exact.


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

Re: [LAD] [ANN] Invada Studio LV2 Plugins 1.2.0

[Ralf Mardorf]

Fons Adriaensen wrote:
> On Sun, Aug 23, 2009 at 07:27:18PM +0100, Dan Mills wrote:
>
>   
>> Lets say your card is aligned so that 0dbFS = +18dbu (EBU standard),
>> then 0Vu = +4dbu = - 14dbFS, so a software VU calibrated for 0Vu =
>> -14dbFs should read the same as an external Vu calibrated for +4dbu =
>> 0Vu. If it does not then either a calibration setting is off somewhere
>> or one of the meters is faulty. 
>> 
>
> True.
>
> But even a definition such as 'dB FS' is ambiguous, and
> it's easy to make mistakes as a result of that.
>
> Consider a sine wave that is just below digital clipping.
> This would be called '0 dB FS', but the actual RMS level 
> is 3 db lower. I've seen at least one context where this
> same signal would be called -3dB FS. Which somehow makes
> sense as well.
>
> AFAIK the first interpretation is the more common one.
>   

'Peak level' vs 'intrinsic level':

* 'dbFS' refers to 'peak level', 'full-scale square wave'
* 'dbFS RMS' refers to 'intrinsic level, 'full-scale sine wave'.

This is how is in Germany distinguished and because of the words on 
English, it might be an international way to distinguish it.

>> actually fairly common with professional cards. 
>> 
>
> And it avoids a lot of problems. Semi-pro cards will not
> have the correct levels, but some can be quite consistent
> between channels. For example my Terratec EWS88MT has less
> than +/- 0.1 dB variation between its 8 channels, both
> for input and output. But the actual level is just +3.5dBu
> for a FS sine wave.
>
> The real misery starts when (as reported in a recent post 
> on LAU or LAD), a user finds four volume controls between
> his audio file and the physical output (plus of course
> a fifth one on his amplifier), and then of course gets
> confused on how to set all of them.

I guess this is the leading point. Even professional IO amps at times 
need calibration.

We should imagine a setup like 'sound card --> tube pre-amps --> 
mastering recorder'. For this scenario a VU meter needs to be an 
external one.

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

[LAD] Selectable limit for polyphony of virtual synth

[Ralf Mardorf]

Hi programmers of virtual synthesizers :)

more than an hour ago I wiped of the dust of my old Oberheim to make 
soundfonts of some basses, but some pad sounds captivated me. The 
Oberheim is limited by 6-voice polyphony, resp. this isn't a limitation 
for those sounds. Virtual synth often tend to make the mix muddy, when 
playing pad sounds, because the polyphony isn't limited, every released 
note is able to end the complete release decay. For the Oberheim some 
notes are cut, while the wanted notes still can play the release decay.

A selectable limit for polyphony might be a feature, that should become 
more common again, not only for virtual analog synthesizers.

I know that e.g. fluidsynth-dssi has a global setting for polyphony, but 
the problem with this is, that it has impact to all used fluidsynth-dssi 
plugins.

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

Re: [LAD] Selectable limit for polyphony of virtual synth

[Ralf Mardorf]

hollun...@gmx.at wrote:
> One obvious question there is:
> what should the synth do when it reaches the limit?
> There are several things that are possible and afaik implemented in
> synths. It could drop the first note played, or the highest, or ...
>
> Just as a hint. I clear the stage for the synth freaks now.
> Philipp

That's right Philip :)

I funk to answer it ;), because my Oberheim has got 6 voices and I 
played 5 voices all the time, I couldn't discern it, but I guess for 
this case it doesn't make a big difference, release only is for 'all at 
last played notes', it can be called 'monophonic polyphony' ;). What you 
are talking about seems to be interesting for synth that needs to manage 
e.g. a limit of 64 voices, but for 16 sounds played by 16 channels. I do 
have such synth, they don't sound like my Oberheim.

The selection needs to be able to enable what I call 'monophonic polyphony'.

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

Re: [LAD] Selectable limit for polyphony of virtual synth

[Ralf Mardorf]

Hannu Savolainen wrote:
> Albert Graef wrote:
>   
>> hollun...@gmx.at wrote:
>>   
>> 
>>> One obvious question there is:
>>> what should the synth do when it reaches the limit?
>>> There are several things that are possible and afaik implemented in
>>> synths. It could drop the first note played, or the highest, or ...
>>> 
>>>   
>> Well, that's called voice stealing. Most synths do it, if they don't
>> have dynamic voice allocation. Usually, you assign voices in a round
>> robin manner, and the oldest note has to go when you're running out of
>> voices.
>>
>>   
>> 
> Ideally the synth should use some kind of priority mechanism when 
> stealing voices. Killing the oldest one is not the best way. For example 
> some kind of psychoacoustic algorithm could be used to find voices that 
> are masked out by the other voices playing at louder levels. Some voices 
> may have decayed to inaudible levels or their pitch may be close enough 
> to the new note to be played.
>
> Best regards,
>
> Hannu

Hi Hannu :)

this is a good idea to cover unwanted cutting. "My problem" is, that 
most virtual synth have enough voices ;). I would like to have the 
effect of old synth, e.g. listen to Peter Gabrial's pad sounds. It's 
wanted to hear the cutting, because it has a musical function, it 
produces ambience. My fault was, that I only referred to the elimination 
of muddy sound by notes with long release times, I've forgotten to bring 
up the musical function.

I like to have the effect that chords will be cut by new cords, similar 
to the effect for monophonic sounds, with one difference, sometimes one 
or two notes shouldn't be cut. There are some very good synth with a 
polyphony of 5 or 6 voices, e.g. the Prophet 5 or the Matrix 6, btw. I'm 
using a Matrix-1000 (the 1000 is for 1000 sounds in the memory, resp. I 
didn't check if the battery is still fine, it might be possible that the 
200 RAM sounds of my Matrix are lost ;)).

For most of my external synth and 'virtual' synth I'm missing this 
effect, they never run out of voices. It's bad not to have enough 
voices, but if you have enough voices than some charm gets lost.

I don't know actual Peter Gabriel recordings, but I bet he still uses 
old synth, e.g. the Fairlight, especially for pad sounds.

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

Re: [LAD] Selectable limit for polyphony of virtual synth

[Ralf Mardorf]

Fons Adriaensen wrote:
> Or some _explicit_ feedback from somewhere downstream the patch
> telling the voice allocator that a particular voice has decayed
> far enough to be a candidate for re-use. My exploratory designs
> for AMS II (gathering dust since four years) did exactly that.

This "was" a very good mechanism at the times when the first synth were 
able to play different sounds for different MIDI channels, but tone 
generators were to expensive, because of technical limits, in the 80ies 
there were no DSP chips, 4MB RAM were very expensive :D etc., I still 
have got a 40 MB hard disk, that was more expensive than the complete 
dual core PC I've today. It's easy to understand that your AMS II is 
gathering dust :). I had to dust my Oberheim ;). It would be suspect if 
somebody would write to the list, that e.g his Linux synth don't have 
enough voices. I often wonder why a lot of  synth emulation don't sound 
as good as the original synth, even if comparing a held note sounds 
identical to an original synth. They differ in their behaviour, when 
playing a song, but not by comparing single held notes. To limit the 
polyphony today seems to be more important for some usage, than thinking 
about not having enough voices :).

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

Re: [LAD] Selectable limit for polyphony of virtual synth

[Ralf Mardorf]

Nick Copeland wrote:
> Voice allocation really depends on what you want the virtual synth to do.
> If you want it to sound like the original then it should use a similar 
> algorithm,
> if you want something that sounds better than or like the original 
> then for
> something like an Oberheim, it will probably not be the voice 
> allocation that
> is lacking on the emulator, more likely the overall quality of the 
> sound that will
> prevent the emulator from being as good: whatever you do with voice 
> allocation,
> if the emulator does not have Oberheim filters and oscillators it will 
> not sound
> like an Oberheim.

I can sample some sounds of my Oberheim and make soundfonts and just 
need a soundfont player, that is able to emulate the voice allocation. A 
lot of sounds can't be emulated by algorithm¹ or layered samples, but 
this isn't what I need, not all sounds are using features that can't be 
sampled.

Btw. there are very good emulations for the ARP step sequencer sounds 
available as proprietary VST or modern external, stand alone synth.

Tonight I'll record some sounds of my Oberheim and then try to work with 
swami to make a soundfont.

Theoretically I don't need any virtual synth, but because on my computer 
there's too much MIDI jitter for external equipment, but no MIDI jitter 
for virtual synth, band-aid should be to sample some of my synth. Might 
become funny for long vector synthesis sounds, that I'll also sample. I 
guess I have to spend 20,- € to pimp my RAM from 2 GB to 4 GB.

Ralf

¹ resp. not today or just by some proprietary plugins
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] Selectable limit for polyphony of virtual synth

[Ralf Mardorf]

Nick Copeland wrote:
> will not sound like an Oberheim.

PS:

And there's no need to sound identically. Even if a programme should 
program something absolutely new, not an emulation, the 'Prophet 
*5*'-'Matrix *6*'-Effect of having less voices, could add some charm.
Btw. I never used the Alsa modular synth, but even an intelligent way 
like Fons described, might be fine for my needs, if it's possible to 
reduce the polyphony to 6, 5 or less voices.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] Selectable limit for polyphony of virtual synth

[Ralf Mardorf]

Jens M Andreasen wrote:
> On Mon, 2009-08-24 at 21:10 +0200, Ralf Mardorf wrote:
>   
>>  Virtual synth often tend to make the mix muddy, when 
>> playing pad sounds, because the polyphony isn't limited, every released 
>> note is able to end the complete release decay. For the Oberheim some 
>> notes are cut, while the wanted notes still can play the release decay.
>>
>> 
> Where do the newly assigned voices start their envelopes from when they
> are stolen from decaying voices? Say "the glass is half empty", will
> they then:
>
> a) "Empty the glass" and start over with a fresh attack from scratch.
> Synced so to say.
> b) Contnue from the level they were at when re-assigned, only that now
> "the glass is half full" instead, and the attack will reach max almost
> immediately.

For the pad sound I played yesterday the Oberheim restarted the 
envelope. I guess this behaviour should be controllable by the way of 
playing, for monophonic synth legato sometimes continues the envelope, 
while for staccato the envelop will be restarted.

> I think the latter could be more expressive when there are no more
> voices than you can easily direct with a single two-handed chord, to get
> in control of the stage again. Six voices would pretty good for that,
> but I remember five like the Prophet had was annoying. Or that at least
> I got lost fighting my own clumpsyness.
>
> Hmmm ... Split 2+4 comes to mind as well.
>   

For this issue I often remember Peter Gabriel, left hand octave bass + 
right hand 3-voice-chords, but yes, sometimes a 4-voice-chord is needed. 
Listen to old Weather Report recordings, when Zawinul played the Prophet 
5. Today Zawinul often plays new synth, with the same sounds, but anyway 
it sounds disgusting today and he's a good keyboarder, able to 
compensate it a little bit, by the kind of playing. I'm a guitarist and 
glad if I get what I wish to have, when playing the keyboard, I'm not 
able to compensate anything by changing my playing technique. I'm 
babbling ;), it's because I'm a fan of some Prophet 5 revisions, 
unfortunately I don't have any Prophet 5.

>> A selectable limit for polyphony might be a feature, that should become 
>> more common again, not only for virtual analog synthesizers.
>> 
>
> ++
>   
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] Selectable limit for polyphony of virtual synth

[Ralf Mardorf]

Paul Davis wrote:
> On Mon, Aug 24, 2009 at 6:13 PM, Ralf Mardorf 
> wrote:
>
>   
>> I don't know actual Peter Gabriel recordings, but I bet he still uses
>> old synth, e.g. the Fairlight, especially for pad sounds.
>> 
>
> he doesn't.
>   

I guess life he still plays old songs sometimes (I should google if he 
is giving concerts?). For Zawinul I know that he don't use old synth any 
more or maybe not all the time and it didn't sound as good as old 
recordings, resp. concert recordings.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [PD-announce] smeck (6ch guitar processing patch) released]

[Ralf Mardorf]

OT:

This reminds me of another issue of polyphony for synth, that is given 
by the Oberheim Matrix-1000 and the Synclavier. There's a special kind 
of mono mode, called 'G' (for the Oberheim). Each of the six voices is 
allocated to it's own MIDI channel, so every voice has got it's own 
pitch bend. Anyway, it's one sound related to some behaviour as far as I 
know, it's not simply like playing 6 monophonic synth. Unfortunately my 
Guitars don't have a MIDI Pickup.

Frank Barknecht wrote:
> Hi,
>
> something for the guitarists around. This is the patch, that Miller Puckette
> explained during the workshop at LAC2008.
>
> Ciao
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] Selectable limit for polyphony of virtual synth

[Ralf Mardorf]

Fons Adriaensen wrote:
> On Tue, Aug 25, 2009 at 12:32:58AM +0200, Ralf Mardorf wrote:
>
>   
>> Fons Adriaensen wrote:
>> 
>>> Or some _explicit_ feedback from somewhere downstream the patch
>>> telling the voice allocator that a particular voice has decayed
>>> far enough to be a candidate for re-use. My exploratory designs
>>> for AMS II (gathering dust since four years) did exactly that.
>>>   
>> This "was" a very good mechanism at the times when the first synth were 
>> able to play different sounds for different MIDI channels, but tone 
>> generators were to expensive, because of technical limits,...
>> 
>
> Note that the idea is *not* to have such feedback for the reasons
> you mention. It is to make such things _explicit_ and user patchable
> so a voice allocator can do more sophisticated things than most do
> today. For example decide that a new note should not be a new voice
> but a continuation of an existing one, depending on some configured
> or even patchable conditions. 
>
> Ciao,

E.g. as a function of legato or staccato played notes to restart or 
continue the envelope?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] Selectable limit for polyphony of virtual synth

[Ralf Mardorf]

Jens M Andreasen wrote:
> I think the latter could be more expressive when there are no more
> voices than you can easily direct with a single two-handed chord, to get
> in control of the stage again. Six voices would pretty good for that,
> but I remember five like the Prophet had was annoying. Or that at least
> I got lost fighting my own clumpsyness.

I misunderstood. Okay, even if a limit is wanted, the limit should have 
a limit for being a limit ;).
Sometimes the Prophet 5 can be a pain, when you like to have no cuts, 
but clean crossings from one 3-voice-chord to another 3-chord voice. In 
practise the change from one 3-voice-chord to another often means only 
to change two of the three notes, while 1 note still is held and because 
of the 2 + 4 split issue, in practise often 4-voice-chords are just 
played by 3-voices and in addition the bass adds the fourth voice. Maybe 
this was Sequential's intent. The Prophet 5 originally doesn't ship with 
MIDI, while later synth like the Oberheim Matrix-1000 have MIDI, so it 
became interesting of taking care that guitars have 6 strings, even if 
80ies synth Pickups were unusable, dunno if it's better today.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [PD-announce] smeck (6ch guitar processing patch) released]

[Ralf Mardorf]

Frank Barknecht wrote:
> "Smeck" is not for midi, but for audio pickups. You need a separate pickup for
> each string.
>   

The Roland GK is designed for MIDI usage. I don't know the actual hex 
pickups. If it's not directly to MIDI, does it mean for Smeck a sound 
card with 6 IOs is needed and the sound of the strings is used as 
wave-source instead of the information about the note, to control 
oscillators as wave-source? Might be a good idea to avoid latency 
because of the pitch detection, but not a big difference to effect 
processors for normal pickups. Hm, I didn't read the link ;).

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

Re: [LAD] Selectable limit for polyphony of virtual synth

[Ralf Mardorf]

Fons Adriaensen wrote:
> On Tue, Aug 25, 2009 at 04:58:32PM +0200, Ralf Mardorf wrote:
>
>   
>>>>> Or some _explicit_ feedback from somewhere downstream the patch
>>>>> telling the voice allocator that a particular voice has decayed
>>>>> far enough to be a candidate for re-use. My exploratory designs
>>>>> for AMS II (gathering dust since four years) did exactly that.
>>>>>   
>>>>>   
>>>> This "was" a very good mechanism at the times when the first synth were 
>>>> able to play different sounds for different MIDI channels, but tone 
>>>> generators were to expensive, because of technical limits,...
>>>> 
>>>> 
>>> Note that the idea is *not* to have such feedback for the reasons
>>> you mention. It is to make such things _explicit_ and user patchable
>>> so a voice allocator can do more sophisticated things than most do
>>> today. For example decide that a new note should not be a new voice
>>> but a continuation of an existing one, depending on some configured
>>> or even patchable conditions. 
>>> Ciao,
>>>   
>> E.g. as a function of legato or staccato played notes to restart or 
>> continue the envelope?
>> 
>
> For example, or to do something special when a note is
> repeated, depending on where in its envelope(s) the first
> one was when its note-off arrived, etc.

Aha, in an extreme case e.g.:

- if the envelope was at point x, then trigger the LFO
- else if it was at point y, then send a program change to an external 
effect processor

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

Re: [LAD] Selectable limit for polyphony of virtual synth

[Ralf Mardorf]

Dennis Schulmeister wrote:
> On Tue, 2009-08-25 at 16:37 +0200, Ralf Mardorf wrote:
>   
>> Today Zawinul often plays new synth, with the same sounds, but anyway 
>> it sounds disgusting today and he's a good keyboarder, able to 
>> compensate it a little bit, by the kind of playing.
>> 
>
> On a side note: Today Joe Zawinul doesn't play any synthesizer anymore
> as he died two years ago. But you're right in that he was a great
> keyboarder from whom one can learn a lot.

Yes, but the synth he played in the last years were not as fine as the 
oldish synth.

Btw. I only know two keyboard geniuses in terms of playing techniques 
for popular electronic music. Zawinul and Worrell. That does not mean 
that other musicians make less good music or that they are less 
virtuosic, but only those two had and one still has got deep impact to 
popular electronic music playing techniques. Can't find the right words 
on English, e.g. Kraftwerk are not less important, but in another way.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [PD-announce] smeck (6ch guitar processing patch) released]

[Ralf Mardorf]

Hi Frank :)

Frank Barknecht wrote:
> Hallo,
> Ralf Mardorf hat gesagt: // Ralf Mardorf wrote:
>
>   
>> Frank Barknecht wrote:
>> 
>>> "Smeck" is not for midi, but for audio pickups. You need a separate pickup 
>>> for
>>> each string.
>>>   
>>>   
>> The Roland GK is designed for MIDI usage. I don't know the actual hex 
>> pickups. If it's not directly to MIDI, does it mean for Smeck a sound 
>> card with 6 IOs is needed and the sound of the strings is used as 
>> wave-source instead of the information about the note, to control 
>> oscillators as wave-source? 
>> 
>
> Yes, that's it - at least on a very, very basic level. Miller's patch for
> guitar is one very advanced beast showing some very cool and cutting edge
> synthesis methods. It's not your run-of-the-mill guitar effects processor. In
> fact it make me want to be able to play guitar. :)
>   

I'm a guitarist, but if I like to play guitar by using my ability, I 
prefer to play the guitar as a classical electric guitar. Even for 
experimental music it is not bad to be able to play guitar, as we can 
hear by listening to Fred Frith and other experimental musicians, but to 
do it there's no need to be able to play guitar.

Have you ever thought about playing the guitar similar to the way a 
Trautonium is played?

Music shouldn't be acrobatic feat, some people know how to play scales 
and chords, but they are to dull to make music, listen to rubbish like 
Dream Theatre.

If you're creative, you can use a guitar even if you aren't a guitarist. 
The advantage of strings is, that you have more impact to the sound by 
your fingers, as if using a keyboard. You don't need to be a guitarist 
to have impact to the sound for experimental music. For 'normal' music I 
can't see any reason to have effects. I only need two effects, an 
overdrive and a compression sustainer to increase the sustain, when 
playing with the bottleneck, but without overdrive. Sometimes in 
addition some other effects are beautiful.

I like guitar synth for experimental music only.

Btw. if you will practise tow years, you are able to play as fast and 
clean as the Dream Theatre guy, even if you don't have any talent. I 
guess you can learn how to play guitar in half a year, with or without 
talent, if you have talent, than you only will be able to play a little 
bit better. I guess guitar is one of the easiest to learn instruments, 
only the beginning give the impression that playing keyboard might be 
easier to do, because playing chords the first weeks seems to be 
impossible, while you don't have such problems when playing chords on a 
keyboard, but this is a wrong impression.

>> Might be a good idea to avoid latency 
>> because of the pitch detection, but not a big difference to effect 
>> processors for normal pickups. 
>> 
>
> It does pitch detection inside of Pd to tune the transformations to the pitch
> played, so you still get a bit of latency (pitch detection is made on blocks 
> of
> 1024 samples afaik.)
>
>   
>> Hm, I didn't read the link ;)
>> 
>
> Maybe you'd want to? Here's the deep link: 
> http://crca.ucsd.edu/~msp/smeck/latest/doc/
> and the pd~convention paper: 
> http://crca.ucsd.edu/~msp/Publications/pd07-reprint.pdf
> rsp. http://crca.ucsd.edu/~msp/Publications/pd07-reprint.dir/
>
> Ciao
>   

Thank you, I'm interested in reading about it, but I won't buy a hex 
pickup for my guitars. I'm not a keyboarder, but good enough to use 
keyboards for my needs, that's why I guess it isn't worth the effort to 
buy a hex pickup etc.. Anyway it's good that some people develop such 
equipment and software.

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

Re: [LAD] [PD-announce] smeck (6ch guitar processing patch) released]

[Ralf Mardorf]

Albert Graef wrote:
> Hmm, 20 msecs at 48KHz doesn't sound too bad. The earliest pitch
> trackers on MIDI guitars had some 250 msecs latency IIRC, now those are
> a real challenge to play. ;-) (Robert Fripp did it, though.)

In a music store I played Voodoo Chile on a guitar synth in the middle 
80ies, the synth sound was played with a latency that might be something 
near to 250 msecs for the lower strings, the high strings had better 
latency. De facto playing was impossible.

As far as I remember Buckedhead played a well working guitar synth for a 
project with Bill Laswell and Bernie Worrell on one of the Praxis 
recordings in the middle 90ies: http://en.wikipedia.org/wiki/Praxis_(band)
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [PD-announce] smeck (6ch guitar processing patch) released]

[Ralf Mardorf]

Paul Davis wrote:
> so in response to somebody else creating tools that they or others
> want to use, you're going to lecture us about how to play a "classical
> electrical guitar"

I guess there's nothing wrong to encourage somebody who guess that he 
isn't able to play guitar, that he anyway should play guitar and ignore 
bullshit like stupid guitar playing, similar to the Roland synth way. 
This was what I did. I wonder what's wrong with you Paul? Not because 
you agitate against me, but because you very often agitates against 
people, even with absolute normal questions and again and again you are 
whining because you earn less money than other coders do. Pleas stop 
making FLOSS if you don't like to do it. Nobody force you to do it and 
nobody force you to read my mails or the mails of the 20 to 30 other 
people you don't like. You're good in slaughtering other people, but 
look who's talking. I'm not in response to somebody else doing anything 
for me, I just made a suggestion, resp. reported what I noticed as a 
reason for differences in the quality of virtual synth and real, 
classical synth.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [PD-announce] smeck (6ch guitar processing patch) released]

[Ralf Mardorf]

Frank Barknecht wrote:
> Not finding an inexpensive and compact 6-channel preamp on the market

I guess there are some less expensive solutions in the web. Some might 
be fine, some not. I would test them on a brad board, maybe this side on 
German is okay: http://www.elektronikinfo.de/audio/egbauanleitung.htm
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [PD-announce] smeck (6ch guitar processing patch) released]

[Ralf Mardorf]

Paul Davis wrote:
> On Tue, Aug 25, 2009 at 3:57 PM, Ralf Mardorf 
> wrote:
>   
>> I guess there's nothing wrong to encourage somebody who guess that he isn't
>> able to play guitar, that he anyway should play guitar and ignore bullshit
>> like stupid guitar playing, similar to the Roland synth way. This was what I
>> did.
>> 
>
> what possible relevance does this have to LAD? miller puckette made
> something possible, and you sounded to me as though you were
> complaining that what he did was a bad idea because it doesn't fit in
> with your ideas of aesthetic creation. i have my own ideas about good
> and bad and terrible ways to make music, and the results thereof, but
> i generally try to keep this to myself, and certainly keep it off LAD.
>  i found your commentary on miller's work rude and insulting, both as
> a wannabe musician and as a developer of FLOSS. if you are not
> interested in what he has done, then just don't bother to comment upon
> it.
>
> of course, i may have misread your comments.

Seems to be a misunderstanding. I like the idea of smeck for doing 
experimental music. If I had enough money I would test it too, but as 
you see, even for people who have hex pickups it needs effort to enable 
the usage of smeck.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [PD-announce] smeck (6ch guitar processing patch) released]

[Ralf Mardorf]

Ralf Mardorf wrote:
> victor wrote:
>   
>> Looks good, but expensive? No price on the site.
>> 
>
> Maybe this one does also enable to use the 6 audio signals by USB: 
> http://de.shopping.com/xPO-Terratec-TERRATEC-Axon-AX-50-USB-SET

http://www.thomann.de/de/terratec_axon_ax_50_usb_set.htm

:(

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

Re: [LAD] [PD-announce] smeck (6ch guitar processing patch) released]

[Ralf Mardorf]

victor wrote:
> Looks good, but expensive? No price on the site.

Maybe this one does also enable to use the 6 audio signals by USB: 
http://de.shopping.com/xPO-Terratec-TERRATEC-Axon-AX-50-USB-SET
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[LAD] [off-list] INVADA meter plugin and DSP load

[Ralf Mardorf]

James Warden wrote:
> [snip] Existing critics on the VU relevance notwithstanding [snip]

Pardon, that some of us make noise because of this, me too. As a rule of 
thumb, there's nothing wrong if you or any other person will use such a 
meter. I'll react my own onesided opinion. Concepts needs to be 
overstated sometimes ;).
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [off-list] INVADA meter plugin and DSP load

[Ralf Mardorf]

:D it should be off-list :D

Ralf Mardorf wrote:
> James Warden wrote:
>> [snip] Existing critics on the VU relevance notwithstanding [snip]
>
> Pardon, that some of us make noise because of this, me too. As a rule 
> of thumb, there's nothing wrong if you or any other person will use 
> such a meter. I'll react my own onesided opinion. Concepts needs to be 
> overstated sometimes ;).
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

In the future I will test ladish. While I don't like jack_snapshot and 
lash very much, I do like qtractor a lot.

I guess a good idea would be not to use a mess of Linux audio apps, but 
one application that stores audio and MIDI connections and is able to 
include virtual synth and fx and is a sequencer and hd recorder, 
qtractor does, qtractor is.

Anyway, if I e.g. like to use Rosegarden because of some features and 
QSampler because I need a GIG, something better than jack_snapshot and 
lash is welcome :).

I'm interested in ladish and glad that somebody did think about the 
features ladish will cover. Hopefully I'll be able to use it, while 
jack_snapshot is easy to use, lash is a PITA.

I'll be very impressed if this should be fine:

"* Collaborate with the X11 window manager so window properties like
   window position, virtual desktop and screen (multimonitor) are
   saved/restored."

Thank you, a good idea to save this too. I'll give ladish a chance.

Cheers,
Ralf







Nedko Arnaudov wrote:
> The first milestone is reached and result is a tarball that brave souls
> may want to download and try. It contains implementation of JACK
> multiconfig functionality. JACK server settings can be saved as part of a
> studio. Then, loading studio will cause JACK settings stored as part of
> the studio to be restored.
>
> Build will produce three operational components:
>  * ladishd - The daemon, a D-Bus service
>  * gladish - GTK GUI interface
>  * ladish_control - Command-line interface
>
> In the tarball you will also find bundled suitable (latest and gratest)
> flowcanvas and LADI Tools.
>
> Download:
> http://ladish.org/download/ladish-0.1.tar.bz2
> http://ladish.org/download/ladish-0.1.tar.bz2.sig
>
> Homepage: http://ladish.org/
> Roadmap: http://ladish.org/roadmap
>
> -
> LADI Session Handler or simply ladish is a session management system
> for JACK applications on GNU/Linux. Its aim is to allow you to have
> many different audio programs running at once, to save their setup,
> close them down and then easily reload the setup at some other
> time. ladish doesn't deal with any kind of audio or MIDI data itself;
> it just runs programs, deals with saving/loading (arbitrary) data and
> connects JACK ports together. It can also be used to move entire
> sessions between computers, or post sessions on the Internet for
> download.
>
> ladish has GUI frontend, gladish, based on lpatchage (LADI Patchage)
> and the ladish_control command line app for headless operation. LADI
> Tools is set of apps that interface with ladish, JACK server and
> a2jmidid
>
> ladish requires D-Bus and JACK compiled with D-Bus support.
>
> LADI Session Handler is rewrite of LASH.
>
> Project goals:
>  * Save and restore sets of JACK (audio and MIDI) enabled
>applications.
>  * Provide JACK clients with virtual hardware ports, so projects can
>be transfered (or backups restored) between computers running
>different hardware and backups. 
>  * Don't require session handling library to be used. There is no need
>of such library for restoring connections between JACK clients.
>  * Flow canvas based GUI. Positions of elements on the canvas are
>saved/restored.
>  * Allow clients to use external storage to save its state. This
>includes storing internal state to non-filesystem place like memory
>of a hardware synth. This also includes storing client internal
>state (client project data) in a way that is not directly bound to
>ladish project. 
>  * Import/export operations, as opposed to save/load. Save/load
>operate in current system and may cause saving data outside of
>project itself (external storage). Import/export uses/produces
>"tarball" suitable for transferring session data over network to
>other computer or storing it in a backup archive.
>  * Hierarchical or tag-based organization of projects.
>  * List of JACK applications. Applications are always started through
>ladish to have restored runtime environment closer to one existed
>before project save.
>  * Distributed studio - network connected computers. Netjack
>configuration is part of the studio and thus is saved/restored.
>  * Collaborate with the X11 window manager so window properties like
>window position, virtual desktop and screen (multimonitor) are
>saved/restored.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

Julien Claassen wrote:
> Hello Nedko!
>I've just got ladish and I'm installing it. I've looked into the 
> requirements. I see there's a lot of GUI and GUI-related, which seems to be 
> required. My question: Could you consider making as much as possible of the 
> GUI-stuff optional. I don't have and I don't need any GUI, so I need to 
> install quite a bit. In any case, the daemon itself doesn't require it, so 
> does the minimum user tool (ladi_control).
>Kindest regards
>Julien

I don't had time to download, compile and install it, but for me ladish 
is interesting because of storing and restoring virtual desktops. I do 
understand that someone wish to have an option not to include storage 
and restore of GUIs and I don't know if the GUI stuff has something to 
do with the desktop stuff, but I think so. To make it optional is a fair 
desire, but please as keep as default to enable any features. ;).
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

Julien Claassen wrote:
> Hello Nedko!
>Now I've come up against a wall, which I don't want to climb.
>It's all to do with GUI-toolkits and their relatives. Especially 
> flowcanvas. 
> I dearly hope and plea for the feature, to optionalise the GUI-parts. 
> Flowcanvas seems to require something ese, which is tedious. Because now I 
> could go on installing ad nauseam, without getting anywhere in a short while.
>Well you might say, that I'm a special case, being blind, having no 
> graphic. 
> But I think this might hit other people as well. People with other 
> main-GUI-toolkits or other commandline friends, and there are some.
>I'd be glad to know, if you're so far along on your way, that you 
> seperated 
> the GUI parts from the real thing.
>Kindest regards
>   Julien

Hi Julian :)

I guess some GUI stuff is important for you too, because I guess Orca 
needs some GNOME GUI stuff ;). Correct me if I'm  mistaken ;). I guess 
you're using Orca for braille all the time and sometimes for speech 
output to?

Btw. if there are alternatives to Orca please inform me (maybe 
off-list), because I sometimes meet some visual impaired people, not 
very often, but some times.

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

Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

Nedko Arnaudov wrote:
> Ralf Mardorf  writes:
> The feature you are mentioning (window positions and virtual desktops)
> is goal that is not achieved yet.
>   

Hi Nedko :)

I guess I'm well known for my unwanted criticism about Linux audio ;). 
Shame on me ;).

I'm glad to see that you plan to include it :). Okay, so for me that 
means, that I don't need to download and compile ladish today, but I 
should have a peep ;).

> The ones Julien talks about

I'm not fine with this, but I suspect that e.g. Orca needs some "GUI" 
stuff, I might be completely wrong ;).

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

Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

Julien Claassen wrote:
> OK, I decided to do a quickie on-list, because I think it might be of 
> interest. This is about blind people and screenreaders. If your not 
> interested, just stop here. No ladish relevance in here. :-)
>   You can use Linux perfectly without any screenreader like Orca or 
> Adriana (Adriane?). Linux offers so many text-based applications, that 
> a blind person can easily stick to the commandline only.
>   For the commandline you only need a braille-display driver. There 
> are two of them: brltty (currently maintained and Debian standard, 
> also needed for Orca) and SBl (SuSE Blinux). Not sure if the latter is 
> still maintained.
>   And yes, if you need to rely on Javascript and other interactive 
> goodies of the web, you would most certainly want a screenreader. The 
> same goes for having to read AND write WORD or OFFICE documents. 
> Reading is no problem, writing is the barrier. :-)
>   Still I'm not sure how much a screenreader would help with the big 
> audio apps. My knowledge is, that some of them bring their own 
> widgets, which Orca finds dificult, and they sometimes use other 
> purely grapical means of control. The latter is true for at least some 
> aspects.
>   Sorry, iff I didn't tell you anything new or interesting. I just 
> thought, it might be the right time to brag a little. :-)
>   Warm regards
>Julien

It's important :)

we're talking about audio and everybody able to see today, can become 
blind tomorrow ;). Anyway applications should have comfortable features 
for people who are able to see (I'm able to see and I like some 
comfortable graphical issues ;)), but it shouldn't be forgotten that 
seeing shouldn't be needed to make music ;) ... we're listening with our 
ears and not our eyes.

Thanks for your advice :).

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

Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

Florent Berthaut wrote:
> Perhaps it already exists, if it does please let me know ;)
>   

As far as I know it doesn't exist. One advantage of Linux is, that most 
desktop environments allow to use virtual desktops, but when making 
music by using Linux, I very often don't turn off the computer, even if 
I have a long rest, because I don't like to set up everything after the 
rest.

I don't know your knowledge about Linux, so I might give a needless 
hint. Take care to run some applications by disabling the usage of the 
PID for JACK clients. Restoring a session by using helping applications 
like jack_snapshot sometimes fail just because of this stupid issue.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

Pardon

> Take care to run some applications by disabling the usage of the PID 
> for JACK client NAMES

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

Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

Florent Berthaut wrote:
> I guess i could used a tiling window manager, but i think it could be 
> interesting to have a more "music-oriented" system which could handle 
> the audio "and" windows sessions.

I like the Ion WM, but I prefer a DE like e.g. KDE. KDE "really" is able 
to remember which Window should have what size and in what position it 
should open. Until today I only miss an application that is able to 
suspend audio sessions to disk and to automatically start them after I 
turn on the computer ;). Btw. I never could use Lash :(.

When making music most times I'm using Linux similar to other platforms. 
I run jack by a command line and only use one application, Qtractor, as 
sequencer and hard disk recorder and I include DSSIs and LADSPAs as 
plugins, instead of using separate applications. So most times I'm 
running the same set up ;).

I welcome ladish, but most of the times I would like to have a 
Linuxsampler DSSI, a Hydrogen DSSI etc. ;).

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

Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

Nedko Arnaudov wrote:
> Ralf Mardorf  writes:
>
>   
>> I welcome ladish, but most of the times I would like to have a
>> Linuxsampler DSSI, a Hydrogen DSSI etc. ;).
>> 
>
> You prefer DSSI over LV2? In recent years I've spent lot of time on both
> JACK session handling problem and LV2. The two technologies have
> something in common and have their pros and cons. I think that both are
> needed. JACK plugins (apps in session handling environment) provide better
> separatation and allow the developer to do more tricks, it is the more
> flexible. LV2 plugins provide less overhead, better match the plugin
> image in users`s heads, but are more restricte. The LV2 GUI problem is
> especially bad, it slows LV2 adoption because hosts and plugins need to
> use same GUI toolkit. LV2 External UI extension maybe will fix this,
> time will tell. Maybe JACK plugins are more viable than LV2
> plugins. After all we have more JACK mini-apps than complex
> LV2+DSSI+LADSPA plugins.

VST, VSTi and LV2 support would be fine, but more common seems to be a 
good working DSSI and LADSPA support for Linux, than a good working VST, 
VSTi support or any support for LV2, even if LV2 is native Linux.

I'm using Qtractor and I guess it comes without LV2 support:

"Qtractor 0.4.2.1376

  Build target . . . . . . . . . . . . . . . . . . .: release

  JACK Audio Connection Kit support  . . . . . . . .: yes
  ALSA MIDI Sequencer support  . . . . . . . . . . .: yes
  General audio file support (libsndfile)  . . . . .: yes
  Ogg Vorbis audio file support (libvorbis)  . . . .: yes
  MPEG-1 Audio Layer 3 file support (libmad) . . . .: yes
  Sample-rate conversion support (libsamplerate) . .: yes
  Pitch-shifting support (librubberband) . . . . . .: yes
  OSC service support (liblo)  . . . . . . . . . . .: yes
  IEEE 32bit float optimizations . . . . . . . . . .: yes
  SSE optimization support (x86) . . . . . . . . . .: yes
  LADSPA Plug-in support . . . . . . . . . . . . . .: yes
  DSSI Plug-in support . . . . . . . . . . . . . . .: yes
  VST Plug-in support  . . . . . . . . . . . . . . .: yes

  XInitThreads() support (DANGEROUS) . . . . . . . .: no

  Gradient eye-candy . . . . . . . . . . . . . . . .: yes
  Debugger stack-trace (gdb) . . . . . . . . . . . .: no

  Install prefix . . . . . . . . . . . . . . . . . .: /usr/local"
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

drew Roberts wrote:
> On Wednesday 02 September 2009 10:37:18 you wrote:
>   
>>> On Tuesday 01 September 2009 19:18:45 Dennis Schulmeister wrote:
>>>   
 That kind of application already exists. It's called a tiling window
 manager. ;) DWM is one I sometimes use although I never tried it for
 audio work.
 
>>> I think what is being asked for is more like a regular window manager
>>> with a
>>> tiling type window manager inside of it that handles the audio apps. Or
>>> perhaps all apps you assign to it. The rest exist outside of the tiling
>>> bit.
>>>
>>> They may want more flexibility inside the tiling part though. It has been
>>> a
>>> while since I fired up a tiling manager and so don't recall details atm.
>>>
>>> (I could be completely off on this read, but is is my take from paying
>>> partial
>>> attention to this thread.)
>>>   
>> No it's exactly what i meant ;)
>> This "tiling window manager" application would handle only the audio
>> applications (or the one you want it to handle) and could be started
>> within any DE . The goal is to combine the advantages of the "all-in one
>> audio app" and of a multiple applications workflow.
>> 
>
> Right, and each app in this meta window could have its window positioned and 
> sized according to the user's wishes and remembered. Right?
>   

This can be done by KDE!
Anyway you can't restore an audio session ;), but you can tell each 
individual window what it has to do after you open it, IIRC excepted of 
the desktop, everything can be remembered, if you set it to remember 
what you want a window to remember.

>> Regards
>>
>> Florent
>> 
>
> all the best,
>
> drew
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
>   

-- 
Secret of Tux: 
http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.jpg
"Gromit bit me" says HMV dog: 
http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg

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

Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

Danni Coy wrote:
> If I were using KDE and I had hardware that supports compositing I 
> would limit my audio software to a single virtual desktop and use the 
> "present windows" desktop effect for the current desktop to be able to 
> see all my windows at once.

You would break stability of your real-time kernel by using a 
proprietary 3D driver? I guess such a driver is needed and I guess 
real-time kernels sometimes aren't fine with those drivers.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

hollun...@gmx.at wrote:
> I'm using a WM (called awesome) that can do tiling for everyday tasks as
> well as audio. Since I have a rather small screen I use it mostly to get
> every app fullscreen. When trying to use it for audio I ran in some
> trouble. Applications like ardour require a lot of screen estate, on my
> screen it hardly fits on the screen. Many other apps have a similar
> minimum size that is simply not handled gracefully, at least by this WM.
> Another problem is with applications that don't resize at all or that
> apparently can't be handled in tiling mode. One such example is jkmeter.
>
> So from my experience with awesome I'd say that it's theoretically a
> nice idea but doesn't quite work that way. When you look at the
> screenshots at tiling WM homepages you see mostly terminals, probably
> for a reason. Maybe other WMs work better, but from my experience I'd
> say that a WM that remembers window positions or where you could
> specify them would probably work better, but I still have to explore
> if that's possible with my WM.
>
> Regards,
> Philipp

When running Ion2 some years ago, there only was one application that 
was hiding a window, IIRC it wasn't an audio application, all other 
applications were fine at maximal 1024x768 or maybe it was just 800x600.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

Dennis Schulmeister wrote:
> Applications that need a lot of space should provide scrollbars. And
> that goes for windows as well as for dialogs. It's a real PITA that many
> applications don't have good scrolling.

Full ACK :). And sometimes they do have scrollbars, but they suppress 
resizing of the window, while the windows by default is very small for 
"normal" large fonts and much to small for people who need "very" large 
fonts.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

james morris wrote:
> [snip] The other extreme, e17, is just ummm, no.

Full ACK.

I like e17, but it was much too buggy some years ago and even today it's 
not a DE I would recommend for a stable DAW. E17 is nice, but not a DE 
for carefree audio productions and it seems that the coders won't like 
to understand what is needed for real-time audio usage. Just my 
experiences. Use e17, but don't use e17 for audio production.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

Ray Rashif wrote:
> How could I forget - e17 actually has _a lot_ of potential. More than 
> KDE as a whole.
>
> http://upload.wikimedia.org/wikipedia/commons/3/36/E17_bw_screenshot.png
>
> But that's all it has - potential.

I'm an e17 and KDE user and IMHO you are wrong, just because KDE is 
stable and e17 very, very often is a PITA. I might be wrong, but I guess 
KDE is able to do nearly everything e17 could do + a little bit more. 
The only reason not to use KDE3 or KDE4 is the usage of resources by 
this DE. In addition I would suggest to use KDE with KWin and not a WM 
that needs proprietary graphics drivers. I'm only referring to the so 
called "pro-audio" usage.

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

Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

Ray Rashif wrote:
> 2009/9/5 Ralf Mardorf  <mailto:ralf.mard...@alice-dsl.net>>
>
> Ray Rashif wrote:
>
> How could I forget - e17 actually has _a lot_ of potential.
> More than KDE as a whole.
>
> 
> http://upload.wikimedia.org/wikipedia/commons/3/36/E17_bw_screenshot.png
>
> But that's all it has - potential.
>
>
> I'm an e17 and KDE user and IMHO you are wrong, just because KDE
> is stable and e17 very, very often is a PITA. I might be wrong,
> but I guess KDE is able to do nearly everything e17 could do + a
> little bit more. The only reason not to use KDE3 or KDE4 is the
> usage of resources by this DE. In addition I would suggest to use
> KDE with KWin and not a WM that needs proprietary graphics
> drivers. I'm only referring to the so called "pro-audio" usage.
>
> Ralf
>
>
> I don't know what you're getting at, but I hope you understand the 
> meaning of "potential". It's evident that e17 has got it right 
> especially when its fancy graphical effects works smoothly on an AMD 
> K6. That's a start, because in that way we know nothing is choking 
> (especially in KWin where there are random artifacts if compositing is 
> disabled). What I'm saying is that it _can_ be comparable to KDE's 
> usability, sometime in the future when it's stable.
>
> For now I have to keep LXDE as a secondary environment.
>
> Anyway what WM needs proprietary graphics drivers?

E17 didn't change a lot since it was the default for the JAD installing 
media some years ago, KDE did change a lot. Yes e17 has got potential, 
that's why I'm using it again, but it's very experimental.  I don't like 
crashs when I try to chose fonts, I like to chose fonts etc., something 
that isn't fine for e17.

All those "show my desktops as a cube and add rain to my windows" and 
make all windows transparent needs proprietary drivers, okay, KWin is 
able to do transparency too, but it still isn't a "show my desktops as a 
cube and add rain to my windows" DE.

Just my 2 cents.

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

Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1

[Ralf Mardorf]

Ray Rashif wrote:
> 2009/9/5 Ralf Mardorf  <mailto:ralf.mard...@alice-dsl.net>>
>
>
> E17 didn't change a lot since it was the default for the JAD
> installing media some years ago, KDE did change a lot. Yes e17 has
> got potential, that's why I'm using it again, but it's very
> experimental.  I don't like crashs when I try to chose fonts, I
> like to chose fonts etc., something that isn't fine for e17.
>
> All those "show my desktops as a cube and add rain to my windows"
> and make all windows transparent needs proprietary drivers, okay,
> KWin is able to do transparency too, but it still isn't a "show my
> desktops as a cube and add rain to my windows" DE.
>
> Just my 2 cents.
>
> Ralf
>
>
> That's right - the word is experimental. If and when it gets out of 
> that phase, which judging from over 8 years (was the e in JAD e16 or 
> 17?) of development so far doesn't look near, it will be a worthy option.

Sorry for my late reply, I'm still short in time :S. It was called e17.

> But saying all that, the irony is that I just installed and updated 
> myself again to the latest intel driver (was previously on a 
> downgraded version due to slow 3D performance), set up KMS, and my KDE 
> 4.3 is looking as good as it never did before. Simply amazing, and 
> surprising because I thought it'd take at least until 2010 to sort 
> that one out.
>
> The first thing to try would be getting messages across the windows, 
> and use double-clicks to select one. Since KWin already has the 
> drawing thing, it's possible to interactively render a cable a la 
> QJackCtl. So this is inter-application communication, which I'm not 
> sure is trivial.
>
> Then again, why go through so much work for the same function? (signal 
> routing; already accomodated for by QJackCtl) It'd just be another 
> step towards fanciness, not sure how effective it'd really be. Once 
> there are too many channels/ports, it'll get to a point where it'll be 
> cumbersome.

-- 
Secret of Tux: 
http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.jpg
"Gromit bit me" says HMV dog: 
http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg

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

Re: [LAD] interesting blog post about syncing blender and ardour

[Ralf Mardorf]

Jörn Nettingsmeier wrote:
> http://www.jpbouza.com.ar/ESP2/tutoriales/gnulinux/blenderardour/id/en

Half asleep I had a quick flip through the howto. It seems to add JACK 
transport support to Blender?! If so, Blender could be synced to other 
applications too, e.g. MIDI sequencers?! Anyway, I guess sync also 
should be possible by using an audio track of Blender for SMPTE, but I 
never tested Linux audio applications synced by SMPTE. Reading LTC, 
SMPTE seems to be possible with Linux and IMO this should be the normal 
way to sync an application like Blender or any other kind of video and 
animation software to any audio and other video equipment, imagine you 
want to mix 3D animations with "real" video recordings, by a Sony 
Betacam, Fastmachine etc. and other common equipment. A SMPTE track 
could sync to every equipment, hardware, software, video and audio, 
anyway an interesting information. Thank you.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] interesting blog post about syncing blender and ardour

[Ralf Mardorf]

Paul Davis wrote:
> 2009/9/20 Ralf Mardorf :
>   
>> Jörn Nettingsmeier wrote:
>> 
>>> http://www.jpbouza.com.ar/ESP2/tutoriales/gnulinux/blenderardour/id/en
>>>   
>> Half asleep I had a quick flip through the howto. It seems to add JACK
>> transport support to Blender?! If so, Blender could be synced to other
>> applications too, e.g. MIDI sequencers?! Anyway, I guess sync also
>> should be possible by using an audio track of Blender for SMPTE, but I
>> never tested Linux audio applications synced by SMPTE. Reading LTC,
>> SMPTE seems to be possible with Linux and IMO this should be the normal
>> way to sync an application like Blender or any other kind of video and
>> animation software to any audio and other video equipment, imagine you
>> want to mix 3D animations with "real" video recordings, by a Sony
>> Betacam, Fastmachine etc. and other common equipment. A SMPTE track
>> could sync to every equipment, hardware, software, video and audio,
>> anyway an interesting information. Thank you.
>> 
>
> SMPTE is a low resolution time code. There is no reason to be limited
> by frame rates of 30 fps when defining a synchronization protocol
> between applications running on the same (or even two networked)
> computer(s). JACK transport is sample-accurate, and as such is
> thousands of times more accurate than SMPTE. even if the final
> destination of the work done in blender (et al) is going to present it
> at approximately 30fps (+/- 6), i can't see any reason to use such a
> limited timecode for this purpose.
>
> obviously, supporting SMPTE timecode is still a good idea, but it just
> doesn't seem ideal for this purpose at all.
>   

You're right that it's better if someone only will use applications like 
Blender and Ardour. On my machine I don't have any sync trouble for 
internal applications, but seemingly because of my hardware I've got 
trouble to sync with external equipment, that's why I like the idea to 
sync internal by JACK transport, especially because I don't have 
external video equipment.

For video studios I guess SMPTE is the better choice. When I was working 
with SMPTE I never had any trouble because of sync, it was accurate enough.

It would be clever to use JACK transport internal Linux machines, but to 
have the option to sync any equipment by SMPTE.

Btw. Blender is less interesting for me, I would like to have sync 
options for 2D animation software and video editing software and to be 
honest, I never needed to use e.g. Cinelerra or Synfig in sync with 
another video or audio application, but having this feature would be good.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] interesting blog post about syncing blender and ardour

[Ralf Mardorf]

Paul Davis wrote:
> 2009/9/21 Jens M Andreasen :
>   
>> On a related subject:
>>
>> http://www.spinics.net/lists/linux-rt-users/msg04866.html
>> 
>
> to cut to the chase: the nvidia binary driver can cause crashes for
> RT-patched kernel users.

I guess some people could use 2D instead of 3D animation software ;). 
But Blender seems to be a more stable and comfortable application than 
all those free 2D applications. There should be an option to use Blender 
without 3D support.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] interesting blog post about syncing blender and ardour

[Ralf Mardorf]

Arnold Krille wrote:
> From my personal experience the rt kernels can also cause crashes without 
> nvidia drivers loaded

I don't have any trouble with rt kernels when not using a proprietary 
(ATI) driver, excepted of jitter for external MIDI. Most times the rt 
kernels are as stable as the latest Atari ST TOS on my machine. 
Something I never would have guessed :). The proprietary driver for my 
ATI graphics doesn't work at all :(.

> while non-rt kernels with nvidia-drivers run stable.
> Based on the fact that since switching "back" to -rt without nvidia some 
> weeks 
> ago, there is less then a 1/3 chance for a clean shut-down...

This might depend on how well the applications and libs fit together. I 
guess for Suse upgraded to the most up to date Linux software this is 
most probably, while for 64 Studio, were everything is tuned by default, 
but also very often outdated, rt kernels seldom cause troubles. For my 
64 Studio there's one exception. I run Qtractor (svn versions) and 
Qtractor isn't included to 64 Studio at all. Qtractor often crashes 
because libfluidsynth isn't a good version for DSSI usage with Qtractor.

 From my experiences it doesn't seems to be the rt kernel, but bad tuned 
applications and libs, that's why I changed from Suse to 64 Studio. 64 
Studio has some disadvantages, for Suse it's possible to run 32-bit 
applications on a 64-bit Suse, e.g. LightScribe software, it's 
impossible to do that on a 64-bit 64 Studio. For Suse it's possible to 
run completely new applications without any effort, while it's 
impossible for 64 Studio.

Such rt kernel trouble seems to depend to the tuning of the installation 
and seldom to the kernel itself. YMMV.

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

Re: [LAD] interesting blog post about syncing blender and ardour

[Ralf Mardorf]

Arnout Engelen wrote:
> On Mon, Sep 21, 2009 at 02:51:26PM +0200, Ralf Mardorf wrote:
>   
>> For video studios I guess SMPTE is the better choice. When I was working 
>> with SMPTE I never had any trouble because of sync, it was accurate enough.
>>
>> It would be clever to use JACK transport internal Linux machines, but to 
>> have the option to sync any equipment by SMPTE.
>> 
>
> I could imagine a 'bridge' between SMPTE and Jack: you could have a Jack
> timebase client broadcasting an SMPTE track, or a Jack timebase master 
> listening to an SMPTE track and keeping the Jack applications in sync with
> it.
>
> jackctlmmc.sf.net seems to do something similar for some MIDI timing. 
>
>
> Beware I might be talking rubbish here though, I've never actually used 
> SMPTE nor MMC :)
>
>
> Arnout

This isn't rubbish, but a good idea :). Btw. SMPTE is similar to MTC and 
for MTC there are some strange behaviours known, e.g. MTC isn't fine 
between a Sequential Studio 440 and an Atari ST running Cubase, while 
both, the Studio and the Atari are fine with being in sync with other 
equipment by MTC. For Linux I had this behaviour too. Some of my 
equipment wasn't fine with Rosegarden, but with Ardour when synced by 
MTC. I never found out why some equipment is fine when synced by MTC and 
other equipment isn't fine, even if this equipment is fine with MTC in 
combination with other equipment. Using SMPTE I never had this trouble, 
but it was always the Atari that wrote and read the time code or it was 
professional Sony and Bosch equipment. In addition a problem might be to 
sync an external video signal to an internal video signal. For analog 
audio signals sync isn't needed, for digital audio signals sync comes 
automatically by e.g. SPDIF, but I don't know if and if so, how analog 
or digital video signals can be synced for home equipment. For 
professional Sony and Bosch equipment there are special sync 
connections. For video cut it's not only important to have the scenes 
synced, but also the signals.

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

Re: [LAD] interesting blog post about syncing blender and ardour

[Ralf Mardorf]

Paul Davis wrote:
> On Mon, Sep 21, 2009 at 12:36 PM, Fons Adriaensen  
> wrote:
>   
>> On Mon, Sep 21, 2009 at 08:18:00AM -0400, Paul Davis wrote:
>>
>> 
>>> SMPTE is a low resolution time code. There is no reason to be limited
>>> by frame rates of 30 fps when defining a synchronization protocol
>>> between applications running on the same (or even two networked)
>>> computer(s). JACK transport is sample-accurate, and as such is
>>> thousands of times more accurate than SMPTE.
>>>   
>> While I'd agree 100% that SMPTE is not what's needed here,
>> your comments on its potential accuracy are misleading.
>>
>> The *data* contained in the SMPTE timecode is quantised
>> to frames. But SMPTE is not just that data. It is data
>> encoded into an audio signal, and this can be resolved
>> to sub-microsecond accuracy.
>> 
>
> when rolling, sure. i'm thinking about a locate command.
>
> its also true that there are variants of SMPTE that include subframes,
> which certainly help the accuracy, but its not clear to me how
> commonly this information is actually passed around.

 From my experiences with SMPTE you need a minimal pre-roll and for 
audio recordings it's common to have one or two bars pre-roll, which is 
much more than enough to get in perfect sync by SMPTE. IIRC even with 
dropouts my analog tape recorder and Atari were in sync within 1/8 note 
and the fine thing is, that when using LTC it should be possible to be 
in sync while jogging or winding, but I can't remember that this worked 
for me at home. For analog (old professional) VTR a pre-roll simply was 
needed to get the spools on speed, I don't think for hard disk audio and 
video recording SMPTE will need a noticeable pre-roll. The accuracy 
seems to be better than what is needed for audio and video. I don't know 
all SMPTE variations and I don't know if there is some newer standard, 
but IMO SMPTE is something that should be supported. I never heard of 
discontent because of using SMPTE and I also never had any trouble 
because of SMPTE. The question might be, if SMPTE would be used by many 
Linux users or not. Btw. one real disadvantage of SMPTE can be 
crosstalk. I prefer a low level for the SMPTE signal with the risk of 
getting more dropouts.

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

Re: [LAD] interesting blog post about syncing blender and ardour

[Ralf Mardorf]

Fons Adriaensen wrote:
> Locating (while stopped) is a remote control function, which
> is not the same as syncing. SMPTE in itself does not support
> anything similar to a locate command, it's not a remote control
> protocol but just an audio signal that can be decoded to time.
>
> SMPTE was developed as a way to sync audio (on magnetic tape)
> to optical film, and later to video. It was also used to sync
> audio tape machines, e.g. two 24-tracks recorders, to each other.
> In all cases the essential trick was to record it on tape as an
> audio track, thereby creating a time reference that was physically
> bound to the real audio tracks on the same tape. Sort of 'soft'
> sprocket holes, with the extra that each such hole also was also
> labeled with its number.
>
> Most machines supporting SMPTE sync would also support locating,
> by combining conventional mechanical tape motion sensing with
> the timecode system, and in the sense that when the master started
> rolling the slaves would chase to approximately the same location,
> then start rolling, then sync accurately. This latter could take
> some seconds, but once sync was established it could be very
> accurate, actually better than a sample at 48 Khz. 
>
> Ciao,

For decades it was used to sync several VTRs by a computers cut list, to 
cut videos and I guess it's still not outdated. Yes, it's very accurate 
(IIRC the precursor of SMPTE was invented for the NASA Apollo missions). 
I guess a noticeable pre-roll only will occur when tape recorders need 
to reach speed, but I don't think noticeable pre-roll is needed for hard 
disks. The big exception for a long delay is film cut, when several 
machines have immense offsets because of cuts and the machines need to wind.

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

Re: [LAD] interesting blog post about syncing blender and ardour

[Ralf Mardorf]

PS:
> The big exception for a long delay is film cut, when several 
> machines have immense offsets because of cuts and the machines need to wind.
>   

So this isn't a disadvantage of SMPTE, but of tape recorders ;).
Again ... the only disadvantage I know is crosstalk. SMPTE isn't a 
friendly audio signal, it's very brutal.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] interesting blog post about syncing blender and ardour

[Ralf Mardorf]

nescivi wrote:
> On Monday 21 September 2009 08:55:56 Ralf Mardorf wrote:
>   
>> Paul Davis wrote:
>> 
>>> 2009/9/21 Jens M Andreasen :
>>>   
>>>> On a related subject:
>>>>
>>>> http://www.spinics.net/lists/linux-rt-users/msg04866.html
>>>> 
>>> to cut to the chase: the nvidia binary driver can cause crashes for
>>> RT-patched kernel users.
>>>   
>> I guess some people could use 2D instead of 3D animation software ;).
>> 
>
> Like this?
>
> http://animata.kibu.hu/
>
> Quite amazing :)
> (it can receive OSC to interact with other software).
>
> sincerely,
> Marije

Hi Marije :)

wow, this is exactly the kind of software I was looking for. Thank you, 
this seems to be excellent software.
Unfortunately there's no Linux version available: 
http://animata.kibu.hu/downloads.html

Will it run on wine? Has anybody from this list used it?

I've got a long todo list and actually no time to test Animata, but I'm 
very curios to give it a chance. Maybe I'll upset plans ;).

I also didn't know http://opensoundcontrol.org/, unfortunately the 
Wiimote isn't for free ;). In the web I found links how to deceive the 
German customs, to get a less expensive Wiimote :D, 
http://www.forumla.de/f-nintendo-wii-forum-31/t-wiimote-wo-am-billigsten-kaufen-49959.
 
I wouldn't be seized with remorse, but the stakes are too high and for 
me it's still to expensive.

Anyway, very interesting software.

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

Re: [LAD] interesting blog post about syncing blender and ardour

[Ralf Mardorf]

Jens M Andreasen wrote:
> On Mon, 2009-09-21 at 17:51 -0400, Paul Davis wrote:
>
>   
>> its also true that there are variants of SMPTE that include subframes,
>> which certainly help the accuracy, but its not clear to me how
>> commonly this information is actually passed around.
>> 
>
> You will always have quarter-frames. No EBU/SMPTE without them. If you
> have the "real" signal, you will then also have the 1KHz bi-phase to
> adjust to. Once locked, you have the video signals pixel-precise
> vsync ..
>
> Locate isn't that critical, would normally be set to place you 4 - 5
> seconds before the actual event (to give you a reasonable count-in) and
> the punch-in/out would then either be performed from a cue-list or just
> manually.

Yes, as I mentioned before, I started my tape recorder most times with a 
pre-roll around 2 bars, at 120BPM 2 bars are 4 seconds, but I only did 
it for audio at home. I worked for professional video studios and IIRC 
vsync needs some kind of additional BNC video connection.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] interesting blog post about syncing blender and ardour

[Ralf Mardorf]

Adrian Knoth wrote:
> On Tue, Sep 22, 2009 at 12:40:36PM +0200, Ralf Mardorf wrote:
>
>   
>>> http://animata.kibu.hu/
>>>   
>> wow, this is exactly the kind of software I was looking for. Thank you, 
>> this seems to be excellent software.
>> 
>
> I just gave it a whirl, and it's fun to play with.
>
>   
>> Unfortunately there's no Linux version available: 
>> http://animata.kibu.hu/downloads.html
>> 
>
> The site is misleading, just checkout the svn and compile it.
>
> a...@hex:/tmp/animata-read-only$ file ./build/animata
> ./build/animata: ELF 32-bit LSB executable, Intel 80386, version 1
> (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not
> stripped
>   

Thank you Adrian :)

I started compiling and now I need to search the web, because of a problem:
http://www.google.de/#hl=de&source=hp&q=error%3A+cast+from+%27Flu_Tree_Browser%3A%3ANode*%27+to+%27unsigned+int%27+loses+precision&btnG=Google-Suche&meta=&aq=f&oq=error%3A+cast+from+%27Flu_Tree_Browser%3A%3ANode*%27+to+%27unsigned+int%27+loses+precision&fp=93dc95491b6a16f1

Any hints are welcome!

i386? Will it run on a 64-bit Linux too? Fortunately I've got still an 
additional Suse installation, Suse on 64-bit architecture seems to 
handle x86 better than Debian/ Ubuntu. Sometimes I'm thinking of going 
back to a 32-bit architecture.

Okay, the todo list for today - cleaning the bathroom and trying to make 
a soundfont with Swami and checking the power switch of my monitor - are 
shunted to a later time.

spinymouse-s...@64studio:/usr/src$ svn co 
http://animata.googlecode.com/svn/trunk/ animata-read-only
[snip]
Checked out revision 49.
[snip]
spinymouse-s...@64studio:/usr/src/animata-read-only$ cat README
[snip]
Installing on Linux
---

In most Linux distributions an FLTK package is available. Animata is 
known to
compile in Fedora, and Ubuntu (8.04, 8.10).

Generic build instructions
--

To build Animata, type:

scons

To run the software, type ./animata in the build directory.
[snip]
spinymouse-s...@64studio:/usr/src/animata-read-only$ scons
scons: Reading SConscript files ...
Checking for C++ library m... yes
Checking for C++ library pthread... yes
Checking for C++ library fltk... yes
Checking for C++ library X11... yes
Checking for C++ library GL... yes
Checking for C++ library GLU... yes
scons: done reading SConscript files.
scons: Building targets ...
g++ -o build/Bone.o -c -Wall -Wno-unknown-pragmas -Wno-long-long 
-pedantic -pthread -Wno-format -DTIXML_USE_STL -DOSC_HOST_LITTLE_ENDIAN 
-DANIMATA_MAJOR_VERSION=0 -DANIMATA_MINOR_VERSION=004 -ggdb2 -O0 
-DDEBUG=1 -I/usr/include -Ibuild/libs -Isrc/libs -Ibuild/libs/tinyxml 
-Isrc/libs/tinyxml -Ibuild/libs/oscpack -Isrc/libs/oscpack 
-I/usr/include/freetype2 src/Bone.cpp
In file included from src/animataUI.h:34,
 from src/Bone.cpp:31:
src/libs/FLU/Flu_Tree_Browser.h: In member function 'unsigned int 
Flu_Tree_Browser::Node::remove(const char*)':
src/libs/FLU/Flu_Tree_Browser.h:1081: error: cast from 
'Flu_Tree_Browser::Node*' to 'unsigned int' loses precision
scons: *** [build/Bone.o] Error 1
scons: building terminated because of errors.

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

Re: [LAD] interesting blog post about syncing blender and ardour

[Ralf Mardorf]

Adrian Knoth wrote:
> [snip]
>
> They use a Node pointer which is then casted to an "unsigned int". This
> works on i386 or wherever sizeof(void*) == sizeof(unsigned int), but
> fails everywhere else.
>
> Find attached a small patch correcting this issue. It's quick&dirty, I
> hadn't much time for it and I don't have any time left for testing. It
> builds, starts and outputs on both, amd64 and i386.
>
> I'll forward the patch to the animata guys for inclusion.
>
>
> HTH
>   

Thank you Adrian :)

this is very kind, but at the moment I need to take a deep breath and 
then I'll continue some other things I've got to do.

Soon I might change to 64 Studio on x86 architecture, because it's 
always the same when using x86_64 architecture.

Btw. I guess I got a link to your patch:

 Original Message 
Subject:Re: [animata-users] Compiling svn revision 49 failed on Ubuntu 
Hardy Linux x86_64
Date:   Tue, 22 Sep 2009 15:20:11 +0200
From:   Ralf Mardorf 
To: animata-us...@lists.kitchenbudapest.hu
References: <4ab8c1a3.4070...@alice-dsl.net> 
<4ab8c249.4030...@kitchenbudapest.hu>



[snip] wrote:
> hi Ralf,
>
> this issue on googlecode might help you:
> http://code.google.com/p/animata/issues/detail?id=38
>
> best,
> [snip]

Hi [snip] :)

thank you very much, but I won't spend time because of this 32-bit vs 
64-bit issue again and again. Has anybody tried to compile it for Suse 
on 64-bit? 32-bit architecture LightScribe stuff that isn't fine for 
Debian and Ubuntu on 64-bit, is fine for Suse on 64-bit. This is really 
a PITA, I'm thinking of reinstalling my Linux on 32-bit architecture, 
but I'm pissed that there seems to be the need to do that. I guess once 
a quarter year I've got trouble because I installed my Linux on 64-bit, 
but 32-bit. I kept Suse 64-bit and Windows 32-bit installations because 
of this issue, instead of removing this installations.

The link you gave me is linking to http://www.gidforums.com/t-18824.html 
and there somebody posted: "Actually, in my opinion, the best bet would 
be to use a 32-bit Linux distribution rather than a 64-bit one"

I'm deeply impressed by Animata. Today I heard the first time of it on 
the Linux audio dev list, btw. I'm not a developer for Linux, but simply 
a user. This is what I've written to the Linux audio dev list: "I've got 
a long todo list and actually no time to test Animata, but I'm very 
curios to give it a chance. Maybe I'll upset plans ;)." And I did upset 
plans, but I'm to short in time to expend effort all the time, because 
the world still is on 32-bit architecture. This is the architecture of 
yesterday.

Again, thank you very much. I guess I'll take a look on Animata using 
Windows and soon change from 64 Studio Linux x86_64 back to x86.

A note to the Artists who made the "Reverse Shadow Theatre" and "Animata 
Jazz Pub" on http://animata.kibu.hu/. This is very beautiful artwork, I 
enjoyed watching it a lot.

Cheers,
Ralf

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

Re: [LAD] interesting blog post about syncing blender and ardour

[Ralf Mardorf]

Paul Davis wrote:
> i've been told by a company that specializes in timecode and shared
> transport control systems that ardour has the fastest and most
> accurate MTC sync of any DAW.

I noticed too that MTC with Ardour is fine, while MTC for some MIDI 
equipment can be a PITA. Compliment :).

I still wonder that you don't like SMPTE. MTC and SMPTE are related, 
there isn't a big difference.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[LAD] Animata or any other 32-bit application on 64-bit by setting up a 32-bit chroot, e.g. for 64 Studio 3.0-beta3

[Ralf Mardorf]

Sorry for this cross-posting, I just want to inform that there might be 
a solution in general for the 32-bit vs 64-bit issue.

Someone from LAD wrote this:

> I tried getting it right, and got it to build on 64bit, but then got seg 
> faults as I wanted to work with layers.
>
> I ended up building it in a 32bit chroot instead (which works fine).

I didn't know about 32-bit chroot :). There's a link on German: 
http://wiki.ubuntuusers.de/32-Bit_chroot

Do you use Ubuntu too?

Thank you for this information, I'll learn about it and test it, Ralf
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] interesting blog post about syncing blender and ardour

[Ralf Mardorf]

Paul Davis wrote:
> On Tue, Sep 22, 2009 at 9:43 AM, Ralf Mardorf
>  wrote:
>   
>> Paul Davis wrote:
>> 
>>> i've been told by a company that specializes in timecode and shared
>>> transport control systems that ardour has the fastest and most
>>> accurate MTC sync of any DAW.
>>>   
>> I noticed too that MTC with Ardour is fine, while MTC for some MIDI
>> equipment can be a PITA. Compliment :).
>>
>> I still wonder that you don't like SMPTE. MTC and SMPTE are related, there
>> isn't a big difference.
>> 
>
> MTC is a different encoding of the same data. SMPTE is an audio signal
> that has be decoded to get time values; MTC is a MIDI event stream
> that has be decoded to get time values. the underlying timeline and
> the resolution of both of them are the same.
>
> i don't like MTC either as a mechanism to share an audio timeline.
> audio has a resolution of 1 sample. our world has been polluted by
> film and video people who think that 1/30th of a second is accurate
> enough. yeah, ok so they added 1/3000th later (subframes) but who uses
> it?
>
> i have nothing against MTC or SMPTE for transport synchronization.
>   

Yes, "transport sync" is the right term and that is waht "we" need.

So the rest, my argumentation, is just blah-blah:

Digital audio audio has got a resolution of 1 sample. Maybe audio and 
light waves have got a resolution of a Planck length?
MTC and SMPTE should sync computers to digital or analog audio or video. 
What "we" need is a sync that is  accurate enough to sync to video half 
frames, film frames, sequencer tics etc. in a way that no phases can be 
heard when 2 machines are playing the same audio signals in unison, film 
cut needs to be possible for exactly 1 picture. This is possible by MTC 
and SMPTE. MTC and SMPTE aren't for sync of digital audio IOs, sync of 
video refresh rates etc..
You might be right, times have changed, maybe something "better" is 
needed for the future, but today MTC and SMPTE are still needed because 
a lot of equipment is using this time-codes and they are accurate enough 
if everything is fine. SMPTE between a Yamaha 4 track tape recorder and 
an Atari ST was good enough to play a synth recorded to the audio tape 
and played by the sequencer in unison, without any noticeable delay, 
even simple click signals for sync, used by the C64, were able to do 
this. Something that isn't fine for my actual Linux PC, because of 
jitter. I know that other people don't have noticeable jitter for their 
Linux PCs, but I guess even for those machines sync isn't without jitter.

There's no need for a theoretical perfect accuracy, "we" only need the 
possibility to sync different machines without noticeable delay.

For people who have better luck than I've got MTC can sync different 
machines to Linux good enough, only SMPTE for some applications is 
missing, because video equipment is using SMPTE and not MTC.

If people will sync blender to a tape recorder or external video machine 
JACK transport or MTC aren't a help.

SMPTE is used by people because it's fine ;), it does what it should do :).
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] interesting blog post about syncing blender and ardour

[Ralf Mardorf]

Dave Phillips wrote:
> nescivi wrote:
>   
>> I tried getting it right, and got it to build on 64bit, but then got seg 
>> faults as I wanted to work with layers.
>>   
>> 
>
> Hi Marije,
>
> I haven't done anything with it (Animata) yet

So you don't know if there will be seg faults when using layers?
Maybe this "32-bit chroot" is the most save way to do it?
Maybe 32-bit chroot also will enable to add other applications, e.g. the 
LightScribe stuff?

Anyway, I'll read about 32-bit chroot. If this should solve the trouble 
for 32-bit applications it might be interesting as a default for 64 Studio.

> , but I also got it built 
> on a 64-bit system (64 Studio 2.1) thanks to some repaired files found here:
>
> http://www.gidforums.com/t-18824.html
>
> Looks like a neat program.
>
> Best,
>
> dp
>
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
>   

-- 
Secret of Tux: 
http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.jpg
"Gromit bit me" says HMV dog: 
http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg

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

Re: [LAD] interesting blog post about syncing blender and ardour

[Ralf Mardorf]

> then either convince someone to finally write a JACK client that does
> the conversion between SMPTE and JACK Transport, or alternatively buy
> a SMPTE<->MTC converter box. they don't cost much (less than someone
> should get paid to write that client, thats for sure).
>   

Stand alone converters are around 300$/€ to 550$/€. Spending that much 
money there are some other proprietary solutions for video and audio 
sync. The problem with interfaces might be, that they only come with Mac 
and Win drivers, but for the same price as such stand alone converters 
they have got some additional features. I wouldn't recommend to use 
Linux with such expensive converters. Spending that much money there are 
better ways for setting up a video and audio machine by using a 
proprietary OS, resp. someone could ask the vendor to write a Linux 
driver too, but I don't think they will do it.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[LAD] Animata on 64bit architecture

[Ralf Mardorf]

nescivi wrote:
> [snip]
> I tried getting it right, and got it to build on 64bit, but then got seg 
> faults as I wanted to work with layers.
>
> I ended up building it in a 32bit chroot instead (which works fine).
>
> [snip]


Hi :)

this isn't really a howto. I guess I made some mistakes, but anyway, 
Animata might be okay. maybe this can help someone else and maybe 
someone else can help me ;).

I'll do a last cross-posting, because this 32bit vs 64bit issue should 
be interesting for this 3 mailing lists.

I tried to install 4 32bit applications to my 64 Studio/ Ubuntu Hardy.
Synaptic is installed, it runs, but dosen't work.
LaCie LightScribe Labeler couldn't be installed.
LightScribe Simple Labeler couldn't be installed, but I tried this one 
with Suse and it's fine on my Suse installs at 64bit.
Btw. I suspect to know what's going wrong, I did something different for 
Animata.
Animata could be compiled, installed and it's running, but I didn't 
tested if it's really fine.

Maybe someone is able to notice what I might have ignored, while I setup 
32bit chroot half asleep.

GParted before 32bit chroot for my 64 Studio 3.0-beta3:

Label studio3.0
Size 6.09 GiB
Used 4.24 GiB
Unused 1.85 GiB

In this case the better way might be to resize the partition before 
setting up the chroot. This must be done from another system, that's why 
I setup the chroot first.

$ sudo -i
# synaptic

Reload and install:

dchroot
debootstrap

# mkdir /chroot
# gedit /etc/schroot/schroot.conf

Add this and replace the user name:

[hardy]
description=Hardy (hardy32)
location=/chroot
priority=3
groups=your_user_name,root
root-groups=root
aliases=default,unstable,ia32
personality=linux32
type=plain
run-exec-scripts=true
run-setup-scripts=true

# rm /etc/schroot/schroot.conf~

The base system installed successfully after 3:12 minutes by:

# debootstrap --arch i386 hardy /chroot/ 
http://de.archive.ubuntu.com/ubuntu/

Gparted now:

Label studio3.0
Size 6.09 GiB
Used 4.44 GiB
Unused 1.65 GiB

# cp /etc/apt/sources.list /chroot/etc/apt/sources.list
# chroot /chroot
# apt-get update

Always ignore warnings about verification etc. and confirm.

# apt-get upgrade

When asked, just enter the encoding of the console.
Ignore:

Processing triggers for initramfs-tools ...
Errors were encountered while processing:
console-setup
E: Sub-process /usr/bin/dpkg returned an error code (1)

# exit
# cp /etc/passwd /chroot/etc/
# cp /etc/shadow /chroot/etc/
# cp /etc/group /chroot/etc/
# cp /etc/sudoers /chroot/etc/
# cp /etc/hosts /chroot/etc/
# cp -r /usr/lib/locale/* /chroot/usr/lib/locale/
# mkdir /chroot/media/cdrom0
# gedit /etc/fstab

Add this:

/home /chroot/home none bind 0 0
/tmp /chroot/tmp none bind 0 0
/dev /chroot/dev none bind 0 0
/proc /chroot/proc proc defaults 0 0
/media/cdrom0 /chroot/media/cdrom0 none bind 0 0

# mount -a

Keep in mind that you've got a backup of the original fstab by /etc/fstab~.

# gedit

Copy and paste this:

#!/bin/bash
/usr/bin/dchroot -d $1

Save it as:

/usr/local/bin/do_chroot

# chmod 755 /usr/local/bin/do_chroot

That's it. Gparted at this point:

Label studio3.0
Size 6.09 GiB
Used 4.52 GiB
Unused 1.57 GiB

Install 32bit application, example #1, Synaptic for 32bit. Open a 
terminal and run $ dchroot -d, it should look similar:

spinymouse-s...@64studio:~$ dchroot -d
I: [hardy-81bb8cf6-4656-4198-943b-fa461c7d100b chroot] Running shell: 
‘/bin/bash’
(hardy)spinymouse-s...@64studio:~$

$ sudo -i
# apt-get install synaptic
# ln -s /usr/bin/synaptic /usr/local/bin/synaptic32

To make the difference of the exit commands clear:

(hardy)r...@64studio:~# exit
logout
(hardy)spinymouse-s...@64studio:~$ exit
exit
spinymouse-s...@64studio:~$ sudo -i
r...@64studio:~# ln -s /usr/local/bin/do_chroot /usr/local/bin/synaptic32

Now you can launch Synaptic for 64bit and Synaptic for 32bit:

For my system this isn't fine:

$ sudo synaptic32

But this is fine for 32bit:

$ dchroot -d sudo synaptic

For 64bit it's still:

$ sudo synaptic

Install 32bit application, example #2, LaCie LightScribe Labeler:

$ cd Desktop
$ wget 
http://www.lacie.com/download/drivers/lightscribe-1.8.15.1-linux-2.6-intel.rpm 
http://www.lacie.com/download/drivers/4L-1.0-r6.i586.rpm
$ dchroot -d sudo synaptic

Reload and ignore warnings because of keys. Then, by ignoring missing 
graphics, install: alien

For me Synaptic doesn't work, but this is fine:

$ dchroot -d sudo apt-get install alien
$ dchroot -d sudo alien 4L-1.0-r6.i586.rpm 
lightscribe-1.8.15.1-linux-2.6-intel.rpm

The output:

I: [hardy-640a3f72-dfc1-400e-aa97-fe6612833770 chroot] Running command: 
“sudo alien 4L-1.0-r6.i586.rpm lightscribe-1.8.15.1-linux-2.6-intel.rpm”
4l_1.0-1_i386.deb generated
Warning: Skipping conversion of scripts in package lightscribe: postinst 
prerm
Warning: Use the --scripts parameter to include the scripts.
lightscribe_1.8.15.1-1_i386.deb generated

$ dchroot -d sudo dpkg -i lightscribe_1.8.15.1-1_i386.deb 4l_1.0-1_i386.deb

It doesn't work, because it seems 

Re: [LAD] (Somewhat OT) Advice needed on distro choice

[Ralf Mardorf]

Fons Adriaensen wrote:
> On Wed, Sep 23, 2009 at 07:30:27PM +0100, Chris Cannam wrote:
>
>   
>> On Wed, Sep 23, 2009 at 7:26 PM, Fons Adriaensen  
>> wrote:
>> 
>
>   
>>> So what distro should I go for ?
>>>   
>> Sounds like Arch is worth a look.
>> 
>
> Do they have a ready-to-use RT kernel ?
>
> Ciao,

I don't think so, 
http://wiki.archlinux.org/index.php/Kernel_Patches_and_Patchsets#-rt, 
but Arch and Sidux seems to be popular for people with similar needs as 
yours.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] MidiSport vs. UA25

[Ralf Mardorf]

Dave Phillips wrote:
> Greetings,
>
> I've been experimenting with MIDI control from one machine to another. I 
> checked the timing of a single note played simultanesouly by instances 
> of QSynth on both machines and was surprised to hear a very noticeable 
> flamming. I then replaced the MidiSport 2x2 with my Edirol UA25 and the 
> flamming disappeared. Both are USB interfaces, btw. MIDI routing between 
> the machines is handled by a Yamaha MJC8 and has never been problematic 
> with that box.
>
> So, my question(s): Is the MidiSport just poorly designed and is there a 
> further condition or module option that can correct the timing delay 
> from that unit ?
>
> Best,
>
> dp

Very interesting!

Are you sure that it is just delay? I've got disastrous jitter with my 
Swissonic USB device. I would be happy if it's caused by the Swissonic 
device. I couldn't check if MIDI would have no jitter when I use the MPU 
of the Envy24 of my TerraTec EWX 24/96 sound card, all circuits I tried 
on a BreadBoard failed and I also didn't test any other interface.

For me it's good news that one of your USB devices fails, while the 
other is fine ;). It gives me hope that just the Swissonic USB device is 
bad.

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

Re: [LAD] MidiSport vs. UA25

[Ralf Mardorf]

>> It is possible that the devices have different buffer sizes, so that
>> sending multiple MIDI messages at once is more difficult.  Have a look
>> at the respective values of wMaxPacketSize that are shown in the output
>> of "lsusb -v".  Furthermore, the devices can have different internal
>> buffers.
>>
>>   
>> 
> Hi Clemens,
>
> Thanks for the information. The report from lsusb indicated that these 
> values:
>
> wMaxPacketSize 0x0020  1x 32 bytes
>   

For me it's "wMaxPacketSize 0x0040  1x 64 bytes", is there a 
boundary value that must result in jitter?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] MidiSport vs. UA25

[Ralf Mardorf]

> Dave Phillips wrote:
>
> Which interface did you use for sending/receiving?
>   

And which USB device is head of the USB devices? Did you change the 
ports or did you edit /etc/default/rtirq?

RTIRQ_NAME_LIST="rtc snd usb3 i8042" You can make a special port head of 
the USB ports by adding the number of the port.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] "Open midi-keyboard"

[Ralf Mardorf]

Fons Adriaensen wrote:
> On Fri, Sep 25, 2009 at 05:07:26PM +0200, Albin Stigo wrote:
>
>   
>> I'm new to the list so I hope this is not the wrong forum!
>>
>> I've been working on a midi keyboard ("physical" hardware 88-keys
>> "professional" = no toy) for a while for which I plan to release the
>> schematics and source as open source.
>>
>> It's based around a Fatar keybed (they make Studiologic) and an Atmel
>> AVR mcu. The code is all in C and is very portable.
>>
>> Current features are:
>> - Velocity sensitivity.
>> - Pedal support.
>> - Custom velocity curves.
>> - Only normal MIDI serial "current" link. No USB, yet...
>>
>> My questions are, Is there an interest in this sort of thing..? What
>> features would you like to see, what are you missing from
>> off-the-shelf products?
>> 
>
> I'd be much interested *iff* it would also generate
> velocity for key release. This is provided in the MIDI
> format but very few keyboars implement it.
>
> Ciao,
>   

For release velocity it's the same as for poly pressure, I don't know 
any keyboard providing this. The only unusual function provided by a 
keyboard I know is breath control. My Yamaha DX7 supports breath control.

I don't think hat there will be a lot of receiving devices that can 
handle release velocity and poly pressure.

A nice feature I can imagine might be to have only 3 or 4 fix velocities 
for each key (maybe this can be done by the "Custom velocity curves") 
and a fix note length (for this the keyboard needs to receive timing 
information by a sequencer), but both, velocity and length for each key 
individually and maybe the length should be set individually by the 
velocity of a note. Why? E.g. to control drum samples. For this it also 
might be interesting to have the option to split the keyboard not only 
in zones, but to enable to give each key a wanted, individual MIDI 
channel. I know that this is also something some sequencers can do by a 
matrix especially for drums, but it might be interesting for a master 
keyboard to.

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

Re: [LAD] "Open midi-keyboard"

[Ralf Mardorf]

Rui Nuno Capela wrote:
> Ralf Mardorf wrote:
>   
>> Christian wrote:
>> 
>>> For the keys I love aftertouch :)
>>>   
>>>   
>> An option that can regulate the number of the aftertouch events that are 
>> send is useful. Some sequencers have an option to reduce the amount of 
>> recorded aftertouch events, but not every sequencer is able to do it. 
>> Using aftertouch sometimes produce too many unneeded data, that can 
>> become a problem.
>>
>> 
>
> talking about aftertouch (aka key-pressure), there's two different
> kinds: "channel aftertouch" (independent of key/pitch) and "polyphonic
> aftertouch" (per key/pitch). the later is seldom implemented but it
> might give an edge on this "open-source midi keyboard" project. it also
> generates a greater amount of events as Ralf warns about
>
> cheers
>   

I never had a keyboard supporting "poly pressure" ($An), they only 
supported "channel pressure" ($Dn), n is for the channel.

Even the common "channel pressure" for some keyboards can cause a lot of 
unneeded data, while played by keyboarders with shaky fingers ;).

Let's say you want to reach an aftertouch level of 120 ($78), this can 
result in a huge amount of $Dn $78, $Dn $77, $Dn $79 etc., running 
status won't reduce a lot of bytes, while there will be data for other 
channels on the same MIDI port.

Another point is, at what value aftertouch should start with level 1. 
Internal a keyboard there should be a resolution of more than 127 steps. 
There should be settings that start aftertouch at soft pressure and 
other settings to start aftertouch at hard pressure.

When using several MIDI ports even a lot of SysEx can be sent real-time, 
but using only one MIDI port even aftertouch can cause timing problems. 
It would be good if there would be some features for the master 
keyboard, instead of using filters or editing functions by a sequencer.

Ralf


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

Re: [LAD] MidiSport vs. UA25

[Ralf Mardorf]

Arnout Engelen wrote:
> On Sat, Sep 26, 2009 at 01:29:53PM +0200, Ralf Mardorf wrote:
>   
>> Arnout Engelen wrote:
>> 
>>> - increased the rtprio for the USB IRQ handler
>>>   
>> How can I do this? I only know how to make my Siwssonic USB MIDI device  
>> head of the USB devices by Rui's rtirq.
>>
>> Is there something I could change for rtirq, to get less jitter for the  
>> USB MIDI device?
>> 
>
> I haven't looked into rtirq yet (I really should)

Hi Arnout :)

or you simply change the USB ports ;).

> , but if I understand 
> correctly rtirq does automatically what I did manually: find out which IRQ 
> the device you're interested in is connected to, and give that IRQ a 
> higher rtprio.
>
> To see the current rtprio's of your IRQ's, do:
>
>   ps axHo user,lwp,pid,rtprio,ni,command | grep irq
>
> To increase the rtprio of some irq manually:
>
>   chrt -f -p  
>   

Thank you :).

Ralf

>>> - decreased the 'latency_timer' value for my wireless network card and 
>>> cardbus
>>>   slot
>>> - tried to increase 'latency_timer' for the USB controller, but it 
>>> remained at 0 - i guess it doesn't support this option
>>>   
>> *?*
>> 
>
> http://irc.esben-stien.name/mediawiki/index.php/Setting_Up_Real_Time_Operation_on_GNU/Linux_Systems#PCI
>
>
> Arnout
>   
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] "Open midi-keyboard"

[Ralf Mardorf]

Fons Adriaensen wrote:
> Soft synths can be made do to whatever you want :-)
> Release velocity adds a new expression possibility
>   

I do agree, anyway it's seldom used.

> that could be interesting in particular for monophonic
> synths. And I'm contemplating writing one...
>   

:)

> Another useful feature (already mentioned by another poster)
> would be a number of digital rotary encoders, and if you have
> any spare AD channels, analog control inputs.
>   

Yes, rotary encoders or just faders would be good, but with the 
possibility that they are easy to program for users, e.g. for SysEx, 
e.g. automatic SysEx checksum. If there are some unused AD channels, 
than input for drum pads, mics etc. might be nice, but not needed by a 
master keyboard.

> About afterpressure, my SL880 only has this for the
> entire keyboard, not per key. It uses a pressure
> sensor strip running along the entire length, and
> is quite difficult to use as it is. Don't know if
> this is due to the sensor being too primitive, or
> to the processing in the SL880's tiny controller.
>   

I've got one of the first DX7 (still in the metal case) and never wanted 
a software update for the DX7. For a synthesizer (it's not a master 
keyboard, even if I use it as my master keyboard) it has got the best 
keyboard I know (there might be other synthesizers having better 
keyboards). The channel aftertouch of the DX7 is very good for "normal" 
usage. I can't remember how Yamaha did it for the DX7 and I won't open 
the DX7, until the battery will be empty. It might be a problem for your 
keyboard because it's a weighted keyboard and the mechanics might be to 
complex for single keys to realize aftertouch as it can be realized for 
simple keyboards. OR! it's just a software problem, that's why I 
recommended to have different start levels for aftertouch. RTo have the 
feeling of a real piano for the keys could conflict with pressure for 
pushed keys. I could imagine that this might be a problem for weighted 
keyboards in general, but I don't know.

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

Re: [LAD] MidiSport vs. UA25

[Ralf Mardorf]

Arnout Engelen wrote:
> I did some tweaks:
> - increased the rtprio for the USB IRQ handler
>   

How can I do this? I only know how to make my Siwssonic USB MIDI device 
head of the USB devices by Rui's rtirq.

Is there something I could change for rtirq, to get less jitter for the 
USB MIDI device?

#!/bin/bash
#
# Copyright (c) 2004-2007 rncbc aka Rui Nuno Capela.
#
# /etc/default/rtirq
#
# Configuration for IRQ thread tunning,
# for realtime-preempt enabled kernels.
#
# This program is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License version 2 or later.
#

# IRQ thread service names
# (space separated list, from higher to lower priority).
# DEFAULT:
# RTIRQ_NAME_LIST="rtc snd usb i8042"
# EDITED TO:
RTIRQ_NAME_LIST="rtc snd usb3 i8042"

# Highest priority.
RTIRQ_PRIO_HIGH=90

# Priority decrease step.
RTIRQ_PRIO_DECR=5

# Whether to reset all IRQ threads to SCHED_OTHER.
RTIRQ_RESET_ALL=0

# On kernel configurations that support it,
# which services should be NOT threaded
# (space separated list).
RTIRQ_NON_THREADED="rtc snd"

# Process names which will be forced to the
# highest realtime priority range (99-91)
# (space separated list, from highest to lower priority).
# RTIRQ_HIGH_LIST="softirq-timer"

> - decreased the 'latency_timer' value for my wireless network card and cardbus
>   slot
> - tried to increase 'latency_timer' for the USB controller, but it remained 
>   at 0 - i guess it doesn't support this option
>   

*?*

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

Re: [LAD] "Open midi-keyboard"

[Ralf Mardorf]

Peter Nelson wrote:
>> For release velocity it's the same as for poly pressure, I don't know 
>> any keyboard providing this. The only unusual function provided by a 
>> keyboard I know is breath control. My Yamaha DX7 supports breath
>> control.
>> 
>
> There are some; my CME UF8 sends release velocity. (It also has breath
> control, though I don't have the controller.)

I also don't have a breath controller. But this issue reminded me of 
another feature.

An option to transform MIDI controllers to SysEx controllers might be good.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] "Open midi-keyboard"

[Ralf Mardorf]

Christian wrote:
> For the keys I love aftertouch :)
>   

An option that can regulate the number of the aftertouch events that are 
send is useful. Some sequencers have an option to reduce the amount of 
recorded aftertouch events, but not every sequencer is able to do it. 
Using aftertouch sometimes produce too many unneeded data, that can 
become a problem.

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

[LAD] rtirq - previously Re: MidiSport vs. UA25

[Ralf Mardorf]

Arnout Engelen wrote:
> I haven't looked into rtirq yet (I really should), but if I understand 
> correctly rtirq does automatically what I did manually: find out which IRQ 
> the device you're interested in is connected to, and give that IRQ a 
> higher rtprio.
>
> To see the current rtprio's of your IRQ's, do:
>
>   ps axHo user,lwp,pid,rtprio,ni,command | grep irq
>
> To increase the rtprio of some irq manually:
>
>   chrt -f -p  

This is from my rtirq: "RTIRQ_NAME_LIST="rtc snd usb3 i8042"" RTC seems 
to be IRQ-8, the sound card is IRQ-21 and the USB MIDI device is IRQ-17.

Why are there IRQ-1 and IRQ-12 having higher rtprio than USB?

Is "usb3" for rtirq correct for "SysFS ID: /devices/[snip]/usb2/[snip]? 
There seems to be no usb0, that's why I guess it's wrong, but I guess 
Rui once has written "usb3".

Is there a reason not to give usb3 a higher rtprio than snd, at least 
when I only need a sequencer?

How can I see which devices do use what IRQ? Perhaps IRQ-17 is used by 
other devices too.

$ ps axHo user,lwp,pid,rtprio,ni,command | grep IRQ
root   104   104 50   - [IRQ-9]
root   402   402 74   - [IRQ-12]
root   403   403 75   - [IRQ-1]
root   411   411 90   - [IRQ-8]
root   971   971 50   - [IRQ-16]
root   992   992 50   - [IRQ-17] *USB MIDI device*
root  1021  1021 80   - [IRQ-19]
root  1028  1028 50   - [IRQ-22]
root  1383  1383 50   - [IRQ-18]
root  1521  1521 50   - [IRQ-14]
root  2082  2082 50   - [IRQ-7]
root  2101  2101 50   - [IRQ-25]
root  2369  2369 85   - [IRQ-21] *Sound card*
root  4302  4302 50   - [IRQ-4]
1000 14174 14174  -   0 grep IRQ



*Only Swissonic MIDI USB device is connected*

$ hwinfo --usb
01: USB 00.0: 10a00 Hub
  [snip]

02: USB 00.0: 10a00 Hub
  [snip]

03: USB 00.0: 10a00 Hub
  [snip]

04: USB 00.0:  Unclassified device
  [Created at usb.122]
  UDI: /org/freedesktop/Hal/devices/usb_device_170b_11_noserial_if0
  Unique ID: FKGF.HOkU9LTmHW8
  Parent ID: pBe4.PaupGMfzSp8
  SysFS ID: /devices/pci:00/:00:13.1/usb2/2-1/2-1:1.0
  SysFS BusID: 2-1:1.0
  Hardware Class: unknown
  Model: "Unclassified device"
  Hotplug: USB
  Vendor: usb 0x170b
  Device: usb 0x0011
  Revision: "0.01"
  Driver: "snd-usb-audio"
  Driver Modules: "snd_usb_audio"
  Speed: 12 Mbps
  Module Alias: "usb:v170Bp0011d0001dc00dsc00dp00ic01isc03ip00"
  Driver Info #0:
Driver Status: snd_usb_audio is active
Driver Activation Cmd: "modprobe snd_usb_audio"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #6 (Hub)

05: USB 00.0: 10a00 Hub
  [snip]

06: USB 00.0: 10a00 Hub
  [snip]

07: USB 00.0: 10a00 Hub
  [snip]

hwinfo --usb-ctrl
[snip] 
24: PCI 13.1: 0c03 USB Controller (OHCI)
  [Created at pci.296]
  UDI: /org/freedesktop/Hal/devices/pci_1002_4388
  Unique ID: 9n5e.Z94ELKUtK5C
  SysFS ID: /devices/pci:00/:00:13.1
  SysFS BusID: :00:13.1
  Hardware Class: usb controller
  Model: "ASUSTeK USB Controller"
  Vendor: pci 0x1002 "ATI Technologies Inc"
  Device: pci 0x4388
  SubVendor: pci 0x1043 "ASUSTeK Computer Inc."
  SubDevice: pci 0x81ef
  Driver: "ohci_hcd"
  Driver Modules: "ohci_hcd"
  Memory Range: 0xfe02d000-0xfe02dfff (rw,non-prefetchable)
  IRQ: 17 (29 events)
  Module Alias: "pci:v1002d4388sv1043sd81EFbc0Csc03i10"
  Driver Info #0:
Driver Status: ohci-hcd is active
Driver Activation Cmd: "modprobe ohci-hcd"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
[snip]



$ hwinfo --sound
09: PCI 306.0: 0401 Multimedia audio controller
  [Created at pci.296]
  UDI: /org/freedesktop/Hal/devices/pci_1412_1712
  Unique ID: Kaa7.J4wu6rKmng4
  Parent ID: qscc.ULOo3yhA66C
  SysFS ID: /devices/pci:00/:00:14.4/:03:06.0
  SysFS BusID: :03:06.0
  Hardware Class: sound
  Model: "TERRATEC EWX 24/96"
  Vendor: pci 0x1412 "VIA Technologies Inc."
  Device: pci 0x1712 "ICE1712 [Envy24] PCI Multi-Channel I/O Controller"
  SubVendor: pci 0x153b "TERRATEC Electronic GmbH"
  SubDevice: pci 0x1130 "EWX 24/96"
  Revision: 0x02
  Driver: "ICE1712"
  Driver Modules: "snd_ice1712"
  I/O Ports: 0xcf00-0xcf1f (rw)
  I/O Ports: 0xce00-0xce0f (rw)
  I/O Ports: 0xcd00-0xcd0f (rw)
  I/O Ports: 0xcc00-0xcc3f (rw)
  IRQ: 21 (26376 events)
  Module Alias: "pci:v1412d1712sv153Bsd1130bc04sc01i00"
  Driver Info #0:
Driver Status: snd_ice1712 is active
Driver Activation Cmd: "modprobe snd_ice1712"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #16 (PCI bridge)
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] "Open midi-keyboard"

[Ralf Mardorf]

Jens M Andreasen wrote:
> On Sat, 2009-09-26 at 14:03 +0200, Ralf Mardorf wrote:
>
>   
>> When using several MIDI ports even a lot of SysEx can be sent real-time, 
>> but using only one MIDI port even aftertouch can cause timing problems. 
>> 
>
> A stream of channel-aftertouch is single bytes, and can at any point be
> interrupted by more important data (note-on) with at most 0.3
> miliseconds delay ...

When interrupted it's 2 bytes, one byte only when running status can 
take effect. To be honest, I don't know if aftertouch will be 
interrupted by applications and devices by default. Is this MIDI 
standard? And to be honest, much more data is produced by the pitch 
wheel, because of the low and high byte. I never had any timing issues 
because of aftertouch and pitch bend, but I noticed that they produce 
much more traffic than real-time SysEx for filters. IIRC I had 4 MIDI 
outputs for the Atari ST, I guess using just one MIDI output can cause 
trouble for pure MIDI music.

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

Re: [LAD] "Open midi-keyboard"

[Ralf Mardorf]

> Jens M Andreasen wrote:
>> On Sat, 2009-09-26 at 14:03 +0200, Ralf Mardorf wrote:
>>
>>  
>>> When using several MIDI ports even a lot of SysEx can be sent 
>>> real-time, but using only one MIDI port even aftertouch can cause 
>>> timing problems. 
>>
>> A stream of channel-aftertouch is single bytes, and can at any point be
>> interrupted by more important data (note-on) with at most 0.3
>> miliseconds delay ...
>
> When interrupted it's 2 bytes, one byte only when running status can 
> take effect. To be honest, I don't know if aftertouch will be 
> interrupted by applications and devices by default. Is this MIDI 
> standard? And to be honest, much more data is produced by the pitch 
> wheel, because of the low and high byte. I never had any timing issues 
> because of aftertouch and pitch bend, but I noticed that they produce 
> much more traffic than real-time SysEx for filters. IIRC I had 4 MIDI 
> outputs for the Atari ST, I guess using just one MIDI output can cause 
> trouble for pure MIDI music.
>
> Ralf

Yes, the Midex had 4 MIDI outs.

Have you tested heavy traffic with just one MIDI port?

I can't speak for aftertouch, but SysEx can become problematic. Okay, 
SysEx always needs to be transmitted from $F0 to $F7, while aftertouch 
can be interrupted, anyway, aftertouch can cause really a lot of data, 
much more than SysEx for filters.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] "Open midi-keyboard"

[Ralf Mardorf]

Nick Copeland wrote:
> I would not put too much emphasis on the ms delays and traffic volume
> generated by these messages. It has been generally agreed that the 
> bandwidth
> of MIDI would have killed it a long time ago had it not been for 
> 'integrated'
> systems that passed MIDI internally hence had no bandwidth limitations and
> that MIDI/USB is keeping it alive today. The device you are talking 
> about has
> a USB connector which can be used at a later date when you need bandwidth
> so perhaps concentrate on functionality for now? Just a suggestion.

Yes the master keyboard might get an USB connector, but master keyboards 
are used to control a set up of equipment and MIDI still is the 
standard. But anyway you're right, there's always the possibility to use 
more than one MIDI port and than MIDI is fine even with heavy traffic.

> b. it is generally low resolution so you hear each step in pressure change

I guess this is a problem when you e.g. will control the volume, but 
controlling the volume by pressure seems to be grotesque. Normal usage 
might be the depth of LFO vibrato, but I do agree, in some cases e.g. 
for controlling filters this can become a PITA.

> Bad targets:
> Volume/gain, filter cutoff, FX depths, : All of these might be normal for
> note-on velocity but are very bad selections for note-off. They cause 
> pops
> and clicks when key-on velocity is very different from key-off velocity.

Seems to be plausible, resp. such targets need a fix note on value, 
while the note off velocity will change this value, but for most cases 
this seems to be groteque.

> Potentially good targets:
> ADSR release rate.

For the release rate this seems to be plausible.

> LFO speeds

E.g. the way a rotary speaker simulation should become slower.

> I think one of the reasons that many synths have avoided doing anything
> with note-off velocity is that the typical targets are not the same as 
> with
> note-on velocity hence there are some semantic issues associated with how
> they need to be directed. Most synths have 'velocity sensitivity', but 
> if it is so
> glib that both values control the same parameter then the results will 
> not be
> what you are probably expecting: they should vary rarely be directed 
> to the
> same synth parameter.

Good thoughts :). I guess you've got experiences with note off velocity. 
I've got experiences with MIDI for around 25 years, but no experiences 
with note off velocity and key pressure.

Your thoughts might be important for people who program virtual synth 
for Linux.

Ralf


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

[LAD] Link to the archive needs an update

[Ralf Mardorf]

It would be nice if someone could add the linuxaudio.org archives to 
http://lad.linuxaudio.org/archive/lad.html. The Stanford archive might 
be less good ;), but search engines prefer to link to lad.linuxaudio.org.

I gave someone on the 64 Studio list links to the Stanford archive and 
was corrected, that there are some more actual LAD archives ;).

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

Re: [LAD] "Open midi-keyboard"

[Ralf Mardorf]

I wrote:
> Nick Copeland wrote:
>
>> Bad targets:
>> Volume/gain, filter cutoff, FX depths, : All of these might be normal 
>> for
>> note-on velocity but are very bad selections for note-off. They cause 
>> pops
>> and clicks when key-on velocity is very different from key-off velocity.
>
> Seems to be plausible, resp. such targets need a fix note on value, 
> while the note off velocity will change this value, but for most cases 
> this seems to be groteque.

Pardon, I'm wrong. But I've got an idea for a master keyboard.

A master keyboard could have an option that could calculate a selectable 
ratio between note on and note of velocity, so that the difference won't 
be to extreme for those targets.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] "Open midi-keyboard"

[Ralf Mardorf]

Fons Adriaensen wrote:
> In a mono synth the release velocity could just be stored
> and used to modify the transition to the next note when
> that arrives.

This might be the most interesting usage. A compression ratio calculated 
by the note on and note off velocity to transmit a changed note of 
velocity might be less useful for a master keyboard, but a master 
keyboard should support custom velocity curves not only for note on 
velocity, but also for note off velocity, anything else seems not to be 
the task of a master keyboard, but a task for the controlled synth.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] "Open midi-keyboard"

[Ralf Mardorf]

Fons Adriaensen wrote:
> On Sun, Sep 27, 2009 at 01:00:25PM +0200, Ralf Mardorf wrote:
>
>
>   
>> ... but a master keyboard should 
>> support custom velocity curves not only for note on velocity, but also for 
>> note off velocity, anything else seems not to be the task of a master 
>> keyboard, but a task for the controlled synth.
>> 
>
> Yes, and in fact the main reason why the velocity curves need
> to be provided by the keyboard is the limited resolution of 
> that paramater in the note-on/off messages.
>
> Ciao,
>   

Are velocity curves for note off a standard for master keyboards? I was 
searching the web for some master keyboards, but only read the seller 
informations. Hm, they have a lot of features, arpeggiator, faders, 
dynamic pads etc.. I wonder if it's possible to manufacture a master 
keyboard in a far smaller edition than big companies do without 
exceeding the price level. Developing a master keyboard and than selling 
it as an assembly kit might reduce coasts, but there are also some 
offers on the market. Btw. a friend has one of Doepfer's first master 
keyboards and it's a bad keyboard, while later master keyboards from 
Doepfer should be good once.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] "Open midi-keyboard"

[Ralf Mardorf]

Jörn Nettingsmeier wrote:
> Ralf Mardorf wrote:
>   
>> Peter Nelson wrote:
>> 
>>>> For release velocity it's the same as for poly pressure, I don't know 
>>>> any keyboard providing this. The only unusual function provided by a 
>>>> keyboard I know is breath control. My Yamaha DX7 supports breath
>>>> control.
>>>> 
>>>> 
>>> There are some; my CME UF8 sends release velocity. (It also has breath
>>> control, though I don't have the controller.)
>>>   
>> I also don't have a breath controller. 
>> 
>
> i've been using "fisherman's friend" to great effect. doesn't do midi,
> though.
>
>
> (sorry, couldn't resist.. ;-D)

OT too: This is funny, but a serious note, Fisherman's friend isn't good 
for vocalists. I guess cheap Whiskey and cigarettes are less bad for the 
voice and give the voice a more rocking nuance. Listen to Tokio Hotel, 
the singers voice is less rocking, because he is young and wasn't 
allowed to buy cheap Whiskey and cigarettes, instead he put some rawness 
by eating Fisherman's friend to his voice. The result of this misuse is 
a hair disease and still a childish voice. Kids, please only take 
Fisherman's friend with permission of your parents.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] "Open midi-keyboard"

[Ralf Mardorf]

David Olofson wrote:
> Very handy for pads and strings where this allows you to control the (usually 
> rather slow) attack and release times individually.
>   

I believe that this will be a good way to control this. Another, not 
perfect way, is something I mentioned some time ago. Limiting the 
polyphony to 5 or 6 voices can handle pad sounds in a very nice way. 
Release will be cut when playing, because of the limit. Some synths e.g. 
the Prophet 5 or Matrix-1000 have some very interesting pad sounds 
because of this effect. Attack also can be controlled by note on velocity.

Anyway, I do agree that note off velocity will be an enrichment and it 
doesn't need any special hardware.

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

Re: [LAD] : "Open midi-keyboard"

[Ralf Mardorf]

Jeff McClintock wrote:
 features would you like to see, what are you missing from
 off-the-shelf products?
 
>
> Hi-Definition MIDI support.
>   

It's not a standard yet, is it? http://www.midi.org/aboutus/workgroups.php
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] phasex-0.12.0-pre1

[Ralf Mardorf]

Oops, wrong list.

 Original Message 
Subject:Re: [LAD] phasex-0.12.0-pre1
Date:   Wed, 30 Sep 2009 14:31:19 +0200
From:   Ralf Mardorf 
To: William Weston 
CC: linux-audio-u...@lists.linuxaudio.org
References: 



William Weston wrote:
> Download phasex and hear for yourself...
>
>  http://sysex.net/phasex/
>
> Alternatively, you can utilize the git repositoty:
>
>  git clone http://sysex.net/git/phasex.git
>   

The screenshots are bright :), I'll compile it within the next days. Is 
there a DSSI version available?

Ralf

-- 
Taking a look at the screenshots reminds me to ask something OT: Does 
anybody know an insiders' tip were to get CME microchips for old 
faithful analog synth by a fair price?

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

Re: [LAD] Open Keyboard: Request for velocity curve information

[Ralf Mardorf]

Fons Adriaensen wrote:
> On Sun, Oct 04, 2009 at 06:50:38PM +0200, David Olofson wrote:
>
>   
>> Well, I don't know about linearity, or how linear MIDI velocity is actually 
>> supposed to be, but it's common to at least have various ways of scaling 
>> velocity. Many (most?) synths will support mapping of velocity per voice to 
>> create "analog" layers (crossfade rather than switch at a distinct 
>> velocity), 
>> and to exaggerate, reduce or disable velocity response and things like that.
>> 
>
> The first question to ask is what is acually measured
> and how, and with which resolution.
>
> Then a range of these values must be mapped to 0..127,

1 to 127, because note on velocity 0 is a note off command.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [ANN] Qtractor 0.4.3 (fussy doula) released!

[Ralf Mardorf]

Rui Nuno Capela wrote:
>   Qtractor 0.4.3 (fussy doula) released!
>   

Hi Rui :)

the last version I compiled was 0.4.2.1401 from svn, build Oct 2 2009 
03:37:02.

For Linux Qtractor still is my favourite one :).

For further versions I would welcome a more comfortable "management" for 
the .mid clips.

When working on a project I save this project by different names, to 
enable it to go back to a later version. For Qtractor there's a problem. 
After editing a MIDI clip, the changed clip is saved under the same 
name, if you leave the editor without using the "save as..." option, 
that means that when loading an older version of the project, the older 
version can't be restored, when it is using the same clip. This is very 
unusual behaviour for a sequencer. Having those .mid files isn't a bad 
idea, but the way they are managed might need some improvements.

Thank you, all in all it's a good piece of software :), even if it's 
still version 0.x.

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