If you are affraid of being early adopter, you should probably not
do test it until contributions of other early adopters make it more
suitable for you.
I'm afraid, but while your reply was received I did ...
$ cd /usr/src
$ wget http://ladish.org/download/ladish-0.1.tar.bz2
$ tar xjf
Ivica Ico Bukvic wrote:
How come the linuxaudio.org mirror (http://download.linuxaudio.org) is not
any more updated with newer releases? Last version available on there is
7.04 which is truly enchant.
What do we need to do to jumpstart this thing again? I presume this would be
something you
Clemens Ladisch wrote:
Busy means that it's there, but already being used. Many motherboard
BIOSes do not initialize the third HPET interrupt, and the first two are
taken by the kernel.
I would like to make a test song using HR timer, but unfortunately I'm
not able to close a project and
Ralf Mardorf wrote:
Clemens Ladisch wrote:
Busy means that it's there, but already being used. Many motherboard
BIOSes do not initialize the third HPET interrupt, and the first two are
taken by the kernel.
I would like to make a test song using HR timer, but unfortunately I'm
Thanx to everybody :). JACK can use hpet and hrtimer is available in
Qtractors options :).
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Emanuel Rumpf wrote:
Opening the hr-timer with rosegarden freezes my whole system here,
what could cause that ?
I guess Open Octave is based on Rosegarden. While Qtractor is fine with
HR timer on my system, Open Octave freezes my system too. I only was
able to push reset, resp. I didn't
Emanuel Rumpf wrote:
Hi
I'm confused about all the timers.
There is:
- system timer
- hpet (high precision event timer)
- hr-timer (high resolution timer)
- rtc (real time clock)
- cyclic (what's that? a coded loop?)
- anything else ?
What is the relation of all these ?
Which
Warden warj...@yahoo.com
Subject: Re: [LAD] timers
To: Emanuel Rumpf xb...@web.de, Ralf Mardorf
ralf.mard...@alice-dsl.net
Cc: linux-audio-dev@lists.linuxaudio.org
Date: Saturday, November 7, 2009, 7:34 AM
Hi guys,
Here is what I have:
$ cat /proc/asound/timers
G0: system timer
Oops, I forgot something too:
spinymouse-s...@64studio:~$ ll /dev/hpet
bash: ll: command not found
spinymouse-s...@64studio:~$ ls /dev | grep hpet
hpet
Ralf Mardorf wrote:
Thank you Emanuel for this thread :)
thank you James for the information :)
hopefully this might narrow down my trouble
is using hr-timer by
default. I wrote this script quite some time ago and forgot about it :)
J.
--- On Sat, 11/7/09, Ralf Mardorf ralf.mard...@alice-dsl.net wrote:
From: Ralf Mardorf ralf.mard...@alice-dsl.net
Subject: Re: [LAD] timers
To:
Cc: linux-audio-dev@lists.linuxaudio.org
Date
Bit internal Linux
- b4: Re: [solved] 'offset/ note length' issue
From:
Ralf Mardorf ralf.mard...@alice-dsl.net
Date:
Tue, 20 Oct 2009 02:47:02 +0200
To:
Rui Nuno Capela rn...@rncbc.org
To:
Rui Nuno Capela rn...@rncbc.org
CC:
qtractor-de...@lists.sourceforge.net
Qtractor didn't
f...@kokkinizita.net wrote:
On Thu, Oct 15, 2009 at 08:55:16AM +0100, victor wrote:
that makes sense now, so someone jumped the gun.
Some time ago I learned on this list the expression
'jumping the shark' - IIRC it was Paul Davis using
it. But what is 'jumping the gun' ?
Ciao,
Jens M Andreasen wrote:
Jumping the Gun is prematurely advertising some event.
Jumping the Shark is inventing new fantastic facts to fit your
bullshit soap-opera script.
Comparing all that English - English idiom explanations on the www I
guess those German translations at www.dict.cc are
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
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
Nick Copeland wrote:
Completely agree that SYSEX is where this kind of functionality should
reside.
This use of 0x7d is a bit antiquated, no? The reassignment of 0x00 to
indicate 3 byte
SYSEX ID means there is a bit more flexibility in the system.
Currently the following
are assigned:
Paul Davis wrote:
On Tue, Oct 6, 2009 at 1:47 AM, Clemens Ladisch clem...@ladisch.de wrote:
David Robillard wrote:
Not enough context quoted to tell; are the stops in Aeolus really too
complicated to be controlled via controllers and programs?
No: For 55 or so organ stops,
Paul Davis wrote:
On Tue, Oct 6, 2009 at 9:08 AM, Ralf Mardorf ralf.mard...@alice-dsl.net
wrote:
Keep in mind that you might want to control 2 devices in unison. You will
send control 7 to both devices, one device is using it for volume and the
other device is using it for anything else
Nick Copeland wrote:
Having everything after 0xf0 as reassignable is a pretty cool idea.
Maybe often used manufacture IDs, eg. Roland, Yamaha, should be excluded ;).
Out of interest, what was the problem with MIDI sequencing and SYSEX?
The only problem I knew about was that they are atomic
Paul Davis wrote:
how do you edit the messages? it requires librarian style
application handling.
As mentioned before I do agree with you Paul, but anyway there are
sequencers like the Atari Cubase that makes it possible that even
absolutely noobs can edit a GUI to edit SysEx by the
Paul Davis wrote:
you've missed my point.
if aeolus is currently programmed to switch to stop setting S1, and i
want it to switch setting S2 instead, what do i, as a user do? what do
i have to know?
I don't know Aeolus, but usually a user should be able to change between
setting 1 and
Nick Copeland wrote:
Does any know if hidef MIDI will address these issues? The MMA is not
very transparent
regarding what they want to put in there.
Some days ago I visited the MMA site and didn't found anything about
hidef MIDI, today I found this, but didn't read it:
so you are saying that in order to edit a sequence that contains
requests for stop changes, the user must understand the *internal*
structure of a sysex message? and this is even more true when they go
to create the first such request (rather than edit an existing one) ?
This depends to the
Pedro Lopez-Cabanillas wrote:
On Monday, October 5, 2009, Fons Adriaensen wrote:
On Mon, Oct 05, 2009 at 07:00:40PM +0200, Pedro Lopez-Cabanillas wrote:
The MMA requires that you use a registered manufacturer ID, but only for
commercial products. There is a special ID = 0x7D that is
The process for the sysex manufacturer ID registration is not only expensive
($200 per year) but also quite ridiculous. It is almost an invitation to
sysexquatting. Have you seen the Recently Assigned Manufacturer ID Numbers
page? http://www.midi.org/techspecs/manid.php
There are a lot
Fons Adriaensen wrote:
On Tue, Oct 06, 2009 at 07:26:18PM +0200, Ralf Mardorf wrote:
I don't know Aeolus, but usually a user should be able to change between
setting 1 and setting 2 by the GUI of the application, just by using the
mouse and without any knowledge about 0xf0 and 0xf7
Paul Davis wrote:
There is no such thing as 'aeolus being programmed to switch to
some stop setting'.
Aeolus has the standard MIDI banks/presets, which you can
load/save from the GUI and recall using the normal MIDI
messages. In most cases that's all that's needed. It also
can use control
Fons Adriaensen wrote:
On Tue, Oct 06, 2009 at 11:33:13PM +0200, Ralf Mardorf wrote:
For the default it would be very easy, 55 * on + 55 * off = 110 settings.
An universal control change is number 6. This could be used to sent by the
data byte 110 different numbers ;), resp. 128.
0
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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.
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
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 f...@kokkinizita.net
wrote:
So what distro should I go for ?
Sounds like Arch is worth a look.
Do they have a ready-to-use RT
nescivi wrote:
On Monday 21 September 2009 08:55:56 Ralf Mardorf wrote:
Paul Davis wrote:
2009/9/21 Jens M Andreasen jens.andrea...@comhem.se:
On a related subject:
http://www.spinics.net/lists/linux-rt-users/msg04866.html
to cut to the chase: the nvidia binary
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
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
x86_64
Date: Tue, 22 Sep 2009 15:20:11 +0200
From: Ralf Mardorf ralf.mard...@alice-dsl.net
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
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
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
Paul Davis wrote:
On Tue, Sep 22, 2009 at 9:43 AM, Ralf Mardorf
ralf.mard...@alice-dsl.net 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
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?
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
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,
Paul Davis wrote:
2009/9/20 Ralf Mardorf ralf.mard...@alice-dsl.net:
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
Paul Davis wrote:
2009/9/21 Jens M Andreasen jens.andrea...@comhem.se:
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
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
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
Paul Davis wrote:
On Mon, Sep 21, 2009 at 12:36 PM, Fons Adriaensen f...@kokkinizita.net
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
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
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
Ray Rashif wrote:
2009/9/5 Ralf Mardorf ralf.mard...@alice-dsl.net
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
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
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
Ray Rashif wrote:
2009/9/5 Ralf Mardorf ralf.mard...@alice-dsl.net
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
Nedko Arnaudov wrote:
Ralf Mardorf ralf.mard...@alice-dsl.net 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
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
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
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
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
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
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
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
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
Nedko Arnaudov wrote:
Ralf Mardorf ralf.mard...@alice-dsl.net 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
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
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,
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
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
: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
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
Paul Davis wrote:
On Mon, Aug 24, 2009 at 6:13 PM, Ralf Mardorfralf.mard...@alice-dsl.net
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
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
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
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
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
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
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
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
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:
Paul Davis wrote:
On Tue, Aug 25, 2009 at 3:57 PM, Ralf Mardorfralf.mard...@alice-dsl.net
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
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
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
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 =
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
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
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
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
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
701 - 800 of 960 matches
Mail list logo
