Le 21 juin 05 à 02:15, ian esten a écrit :
would it not be possible to have the midishare to jack bridge buffer
events that are timestamped in the future, and then schedule them in
realtime in the process callback?
ian
This would require *each* client to have its own scheduler... (since
eve
would it not be possible to have the midishare to jack bridge buffer
events that are timestamped in the future, and then schedule them in
realtime in the process callback?
ian
On Mon, 2005-06-20 at 10:53 +0200, Stéphane Letz wrote:
> I would say that one the may problem is that jack MIDI does not
Christoph Eckert <[EMAIL PROTECTED]> writes:
> About reconnecting I wonder if the applications could do it
> themselves and transparently as soon as JACK reappears. I did
> notice that it takes a lot of time to reconnect after I had
> to restart JACK.
They can and they should. AFAICT, most cu
On Tue, 2005-06-21 at 02:16 +0200, Joachim Schiele wrote:
> What is the rationale for doing anything? Fun? Sex? Ego? Evolution? Nonsense?
Joachim!
Most of what I do, I do out of curiosity, as in: What if?
Having said that, most of your question marks fits straight in. They are
good questions!
On Tue, 2005-06-21 at 02:16 +0200, Joachim Schiele wrote:
> On Tuesday 21 June 2005 01:59, Jens M Andreasen wrote:
> > On Tue, 2005-06-21 at 00:10 +0200, Christoph Eckert wrote:
> > > > > (And remember GNOME & KDE are multi-platform - so I don't
> > > > > think GNOME & KDE apps can use ALSA directl
> At times, even I am a relaxed consumer :)
as well as the other way around - so no borders please :) .
Best regards
ce
> Maybe I am stupid and therefore I have to ask: What is the
> rationale for running KDE (or Gnome?) in an MS Win
> environment?
It's geeky ;-) .
Best regards
ce
> The best place to sort this out is probably
> http://freedesktop.org/ That is where GNOME & KDE agree on
> interoperability issues.
gstreamer seems to be one candidate.
> If you can get GNOME & KDE to agree I'm pretty sure the
> distros would follow. It's just a matter of coming up with
> a go
> Of course they can use ALSA, but only indirectly via some
> cross-platform API (like jack/esd/aRts/polypaudio).
Portaudio comes to my mind. It's already used by audacity.
Best regards
ce
On Tue, 2005-06-21 at 01:32 +0200, Christoph Eckert wrote:
> > > agreed, "creative" vs. "consumptive".
> >
> > Yes! :)
>
> but I still hope that we do not draw an artificial border
> between those two groups :) .
No artificial borders, No! Only real borders driven by practical
considerations.
T
On Tuesday 21 June 2005 01:59, Jens M Andreasen wrote:
> On Tue, 2005-06-21 at 00:10 +0200, Christoph Eckert wrote:
> > > > (And remember GNOME & KDE are multi-platform - so I don't
> > > > think GNOME & KDE apps can use ALSA directly.)
> > >
> > > They don't have to use ALSA directly, but they can
On Tue, 2005-06-21 at 00:10 +0200, Christoph Eckert wrote:
> > > (And remember GNOME & KDE are multi-platform - so I don't
> > > think GNOME & KDE apps can use ALSA directly.)
> >
> > They don't have to use ALSA directly, but they can use a
> > common library which uses ALSA directly like polypaudi
> > agreed, "creative" vs. "consumptive".
>
> Yes! :)
but I still hope that we do not draw an artificial border
between those two groups :) .
Best regards
ce
On Tue, 2005-06-21 at 00:46 +0200, Christoph Eckert wrote:
> > When we say 'pro', it would make much more sense if we
> > could agree on that this means "produzione" rather than
> > "profezionale".
>
> agreed, "creative" vs. "consumptive".
Yes! :)
>
>
> Best regards
>
>
> ce
>
--
> When we say 'pro', it would make much more sense if we
> could agree on that this means "produzione" rather than
> "profezionale".
agreed, "creative" vs. "consumptive".
Best regards
ce
> I don't have any problem with having number of different
> driver models, especially when number of different ways to
> abstract those exist already.
you're almost right, if /dev/dsp is the thing for you, you
should be allowed to use it.
Unfortunately, for ALSA we have no finally DMIX availab
Hi!
There has been some discussion lately involving keywords such as
"amateuer" and "professional".
An "amateur" works for the love of it (as in 'amore'.)
A "professional" works to earn his/her daily bread (as in
'proffezione'.)
Those two concepts are not mutuallally exclusive per se. It is not
> -OSS/ALSA Conflicting modules in hotplug. Hotplug seems to
> make a mess in many systems i've seen, of loading ALSA and
> OSS modules at the same time, by rendering the system audio
> unusable.
I also had a lot of trouble which have gone since I did
disable all OSS stuff in the kernel. Don't f
> as far as user is concerned various apps suddenly get
> frozen, there's no indication they tried to play audio and
> then you have e.g. mozilla looking like it's frozen becuase
> one or another plugin (flash usually) tries to open
> audio...
then the application should be able to provide an
> > (And remember GNOME & KDE are multi-platform - so I don't
> > think GNOME & KDE apps can use ALSA directly.)
>
> They don't have to use ALSA directly, but they can use a
> common library which uses ALSA directly like polypaudio.
That's true. KDE also runs on other operating systems like BSD
> > -OSS/ALSA Conflicting modules in hotplug. Hotplug seems
> > to make a mess in many systems i've seen, of loading ALSA
> > and OSS modules at the same time, by rendering the system
> > audio unusable.
>
> compiling a kernel to have both OSS and ALSA modules around
> makes a mess of many systems
> > -Adding/Removing softsynths, linking connections, etc
> > takes a while having to use qjackctl, etc
>
> tell me a system in which this not true. i use the patchbay
> in qjackctl; if you don't like qjackctl, i'm sorry and i am
> sure rui is as well.
Sometimes I like to use patchage instead of
> -Saving/Restoring your project is just painfully hard. LASH
> doesnt help, and even when I came up with the idea of it in
> the first place.
In my opinion an application shoud remember the last used
document and optionally reload it at start time...
> -Adding/Removing softsynths, linking
> c
> I remember how happy I once was when I found libao to avoid
> the parallel ALSA/OSS existance problem when coding a very
> small application that basically just wanted to deliver
> output. I wonder how hard it would be to write one library
> that does the multiplexing and autodetection/config p
> > * When JACK gets restarted it would be great if running
> > JACK applications wouldn't need to be restarted.
>
> they don't need to be. ardour, xmms-jack and freqtweak can
> all by reconnected; xmms-jack actually does it
> automatically.
cool, I didn't notice it but to be honest I did update
On Mon, 2005-06-20 at 19:11 +0200, Olivier Guilyardi wrote:
> I have never coded with midi, neither with osc. What's the fastest and
> smartest
> way to achieve this idea ?
Midi will be the fastest and smartest.
Osc may be in principle be smarter, but considering the hardware at
hand, won't buy
On Mon, Jun 20, 2005 at 09:28:53PM +0200, Florian Schmidt wrote:
> App A is a sequencer having two tracks at two different meters (i'm
> thinking polyrythmic here, so the meters/tempi might be related (just to
> make a point about the usefulness of this)).
>
> Now there's Apps B and C. B should be
On Mon, 20 Jun 2005 20:49:36 +0200
Tim Orford <[EMAIL PROTECTED]> wrote:
> > The reason for this opinion of mine is that musical time is simply too
> > complex to be handled by one general mechanism. Think of different apps
> > using different meters, etc.. Or even a single app using different
> >
On Sun, 2005-06-19 at 15:02 -0400, Lee Revell wrote:
> Skype and other closed source apps which refuse to support ALSA
> properly, leading to tons of useless bug reports and users blaming the
> problem on ALSA.
> A close second is bonehead vendors like Nvidia who STILL won't release
> enough info
On Mon, Jun 20, 2005 at 07:34:28PM +0200, Florian Schmidt wrote:
> > you can't do tempo-map based transport without sharing the tempo map.
> > nobody has suggested a way to do this yet. please feel free.
>
> Here i would like to chime in :) I think the mapping of BBT to frames
> and the other way
On Mon, 2005-06-20 at 15:48 +0200, Alfons Adriaensen wrote:
> [Tim Orford]
>
> > although "pros" have some valuable knowledge, one of the funny
> > things about them (and i am guilty of this) is that they all
> > think other pros are like them, which is not remotely true.
> > There are big diffe
On Mon, 20 Jun 2005 11:57:24 -0300
Juan Linietsky <[EMAIL PROTECTED]> wrote:
> I talked with florian schmidt on irc about this, some time ago.
> But my impression from what he said is that most jack
> developers wanted to keep tempo map sharing in a
> separate library, not inside jack. I think he
On Mon, 20 Jun 2005 09:50:53 -0400
Paul Davis <[EMAIL PROTECTED]> wrote:
> > -Jack lack of OSC or any way to do parameter automation from the sequencer
>
> name one platform that allows this. just one.
There's none that i know of, but it would be cool to have anyways :)
> > -It is Impossible to
On Mon, 2005-06-20 at 13:26 -0300, Juan Linietsky wrote:
[stuff about manual IO post config deleted]
> So, my main question is *why* isnt this autodetected by the
> driver/kernel by default?
Because unlike Windows, we don't have complete hardware specs, so lots
of guesswork and trial and error
On Mon, 2005-06-20 at 17:48 +0200, Joern Nettingsmeier wrote:
> Jonathan Corbet wrote:
> > Garett Shulman wrote:
> >
> >>There is a length sumerry of the LKML RT discussions here:
> >>http://kerneltrap.org/mailarchive/1/message/76742/thread
> >
> > I hope I won't sound too self-serving if I point
Hi,
I am thinking about adding midi or/and osc support to Jackbeat
(http://xung.org/jackbeat). My idea is to use a hardware midi controller such as
the evolution uc33 to control pitch, volume and muting on every tracks. This
would help using Jackbeat for live performances.
I have never coded
At Mon, 20 Jun 2005 13:26:06 -0300,
Juan Linietsky wrote:
>
> Takashi Iwai wrote:
>
> >>-Module configuration parameters. WHY ON EARTH do I have to specify the
> >>IO port for mpu401, joystick, etc as driver options when loading the
> >>modules for my soundcard, else doesnt work? What year are
At Thu, 16 Jun 2005 10:30:29 -0400,
Paul Davis wrote:
>
> > > i don't think that, even if we had had fons on board at that time, that
> > > the idea of using a DLL rather than interrupts to truly drive the whole
> > > system would have occured to anyone in 1996-2000.
> >
> > Probably not, but I r
At Sat, 18 Jun 2005 20:59:11 -0400,
Ivica Ico Bukvic wrote:
>
> I think that the core question is do Windows and OS X users have to know
> anything about "sound servers" to get multiple applications to talk to the
> soundcard? The answer is obviously no.
>
> The second question is do Windows and
Takashi Iwai wrote:
-Module configuration parameters. WHY ON EARTH do I have to specify the
IO port for mpu401, joystick, etc as driver options when loading the
modules for my soundcard, else doesnt work? What year are we on?! I cant
believe that this resource allocation is not handled by ALSA
Jonathan Corbet wrote:
Garett Shulman wrote:
There is a length sumerry of the LKML RT discussions here:
http://kerneltrap.org/mailarchive/1/message/76742/thread
I hope I won't sound too self-serving if I point out that LWN has been
covering this issue all along.
definitely not. lwn's cove
At Sun, 19 Jun 2005 16:01:39 -0400,
Lee Revell wrote:
>
> >SOUNBLASTER LIVE MIXER:
> >
> >total mystery
>
> This was never really an ALSA problem. The confusion due to the large
> number of mixer elements is resolved with recent versions of alsamixer
> (by splitting the controls into Pl
At Sun, 19 Jun 2005 12:42:34 -0700,
Erik Steffl wrote:
>
>looks like dmix solves the problem but it seems like it's not that
> easy to set it up (I haven't tried since I have soundcard with hw
> support for multiple channels).
This should have been improved. If you still have difficulties
At Sun, 19 Jun 2005 22:41:03 -0300,
Juan Linietsky wrote:
>
> ALSA related, I hate:
>
> -Dmix. It's not fair, why not the windows/beos approach which uses
> primary/secondary buffers? so you can
> AT THE SAME TIME access asyncronously to the audio device (Jack) and
> have lower priority audio m
Hi, Mario:
Mario Lang writes:
> Hi.
>
> Since I finally ordered my Multiface, I also started to write
> a small program which I am going to need since hdspconf and hdspmixer
> are both GUI only.
>
> The idea:
> hdsposc will offer the RME mixer and the metering functionality
> via OSC.
>
> Why
Alfons Adriaensen wrote:
... many musicians today can rightly be called audio professionals
in the sense that they use audio production equipment that was the
specialist domain of trained audio engineers not some many years ago.
But this does not mean
Audio professional == Musician.
I've h
Paul Davis wrote:
-Dmix. It's not fair, why not the windows/beos approach which uses
primary/secondary buffers? so you can
you know what? there is plenty about the design to complain about, but
when i complain about it, i willingly admit my own complicity in the
mistakes that were made. A
> discipline. The differences are not overcomable, and i think you would
Sorry, as Fons pointed out in his "+5 Insightful" comment, this should
have been "not *un*overcomable", or even "*are* overcomable"...
--
Tim Orford
Paul Davis wrote:
-Alsa/Jack integration in timestamping is poor, syncronizing audio to
midi is a pain
i suspect that you don't understand (or perhaps even know about) the
DLL-driven jack_frame_time().
What is DLL-Driven? I used jack_frame_time() in chionic, It works, but it's
not en
I was only answering to the initial question of wether a MidiShare
like API (where event scan have future timestamps, to be delivered
at their due time to clients by the mean of a scheduler) could be
built on top of the jack Midi API the way it is designed. And the
answer is probably not.
the
At Mon, 20 Jun 2005 11:33:18 +0100,
Damon Chaplin wrote:
>
> On Sun, 2005-06-19 at 11:34 -0400, Dave Phillips wrote:
>
> > Ideally we'd be rid of artsd, esd, and all the legacy from OSS/Free.
> > We'd have one sound server (JACK?) and software mixing would be enabled
> > by default. The remai
At Mon, 20 Jun 2005 00:23:57 +0200,
Christoph Eckert wrote:
>
>
> > But the core ALSA developers work for SuSE. There must be
> > some other explanation for this one.
> >
> > Maybe they just felt that dmix was not ready until
> > recently. Or maybe their desktop people really do not ever
> > ta
Dave Phillips wrote:
Greetings:
The subject says it all.
My own "Linux audio sucks" hobbyhorse:
No way to recall a complex configuration of apps and plugins with all
settings intact. If I use a complicated setup with multiple synths and
plugins I have no way to recall these applications
Hi,
GNUsound 0.7.2 was released. This release fixes a few naggling issues
and incorporates support for the gmerlin avdecoder, which provides the
ability to load .AAC and Musepack formats (among many others).
Changes from 0.7.1:
Fixed undo issues with Mix Tool, Move Tool, Pencil Tool.
Fixed ILLEG
Le 20 juin 05 à 14:33, Benno Senoner a écrit :
Stéphane Letz wrote:
Good question
I would say that one the may problem is that jack MIDI does not
has the concept of time-stamps in the "future" . The Jack MIDI
"events" are received in real-time (similar to what MidiShare does
wit
> It is the same problem you have when you use alsaseq+jack. The typical
> hack to fix this is to have a separate thread receiving and timestamping
> events, but this is plain SHIT because you have to anyway rely on the
> lowlatencyness of the kernel to not jitter the alsa/osc IPC.
if the kerne
> -Dmix. It's not fair, why not the windows/beos approach which uses
> primary/secondary buffers? so you can
you know what? there is plenty about the design to complain about, but
when i complain about it, i willingly admit my own complicity in the
mistakes that were made. ALSA has been under dev
> -Alsa/Jack integration in timestamping is poor, syncronizing audio to
> midi is a pain
i suspect that you don't understand (or perhaps even know about) the
DLL-driven jack_frame_time().
> -Jack lack of midi
as noted, released and undergoing subtle revisions as it moves towards
CVS.
> -Jack l
[Lachlan Davison]
> ... from a dance music making perspective i'm not sure if i
> understand this customer concept. Does your fav rock band use
> "best practice" and professional conduct? are they not professional?
[Dave Phillips]
> I'm a music professional. I make my living teaching music, writ
> * When JACK gets restarted it would be great if running JACK
> applications wouldn't need to be restarted.
they don't need to be. ardour, xmms-jack and freqtweak can all by
reconnected; xmms-jack actually does it automatically.
> In the System Preferences->Sound menu, a user
> can choose the default audio input and audio output
> device.
>
> In the CoreAudio API, this choice becomes the
> current value of kAudioHardwarePropertyDefaultInputDevice
> and kAudioHardwarePropertyDefaultOutputDevice.
>
> Consumer-oriented apps
On Mon, 2005-06-20 at 14:40 +0200, Jens M Andreasen wrote:
> On Mon, 2005-06-20 at 11:33 +0100, Damon Chaplin wrote:
>
> > (And remember GNOME & KDE are multi-platform - so I don't think GNOME &
> > KDE apps can use ALSA directly.)
>
>
> If Gnome/KDE can't use the native sound system in Linux,
On Mon, 2005-06-20 at 11:33 +0100, Damon Chaplin wrote:
> (And remember GNOME & KDE are multi-platform - so I don't think GNOME &
> KDE apps can use ALSA directly.)
If Gnome/KDE can't use the native sound system in Linux, then, ehrmm ...
Then the port is incomplete, and they are simply not reco
Stéphane Letz wrote:
Good question
I would say that one the may problem is that jack MIDI does not has
the concept of time-stamps in the "future" . The Jack MIDI "events"
are received in real-time (similar to what MidiShare does with the
Receive callback concepts) but have also to be d
On Mon, 2005-20-06 at 13:06 +0200, Tim Orford wrote:
> On Sun, Jun 19, 2005 at 10:22:02PM -0300, Juan Linietsky wrote:
> > -Saving/Restoring your project is just painfully hard. LASH doesnt help,
>
> some interesting points there. Would you mind elaborating on the
> problems with LASH? Are they d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sunday 19 June 2005 18:01, Dave Phillips wrote:
> Greetings:
>
> The subject says it all.
>
> My own "Linux audio sucks" hobbyhorse:
>
> No way to recall a complex configuration of apps and plugins with
> all settings intact. If I use a comp
On Sun, Jun 19, 2005 at 10:22:02PM -0300, Juan Linietsky wrote:
> -Saving/Restoring your project is just painfully hard. LASH doesnt help,
some interesting points there. Would you mind elaborating on the
problems with LASH? Are they design or implementation problems?
cheers
--
Tim Orford
On Sun, 2005-06-19 at 11:34 -0400, Dave Phillips wrote:
> Ideally we'd be rid of artsd, esd, and all the legacy from OSS/Free.
> We'd have one sound server (JACK?) and software mixing would be enabled
> by default. The remaining question is how to make this mandatory for at
> least the mainst
In the absence of any scheduling mechanism, I don't think the
MidiShare API could be re-built on top of the underlying Jack MIDI
buffer transports system.
but .. what about having Jack just use MidiShare Events (the 'other
way around'), or is this a futile idea?
/hasn't seen the jack-midi co
Le 20 juin 05, à 10:19, Jay Vaughan a écrit :
At 19:13 -0700 19/6/05, ian esten wrote:
just a small correction: jack midi is not yet in cvs. if anyone wants
to
use it, they have to grab the latest set of files and patches from the
jackit-devel mailing list, and apply them to jack >= 0.99.0. i
On Fri, Jun 17, 2005 at 11:27:14AM -0600, Garett Shulman wrote:
> Asbjorn, LDAS looks perfect. Can you give more detail about the status?
> -Garett
Did you read the info I linked to?
http://www.q2s.ntnu.no/~asbjs/ldas/ldas.html >
It is, it must be said, still in early development. But some basi
At 19:13 -0700 19/6/05, ian esten wrote:
just a small correction: jack midi is not yet in cvs. if anyone wants to
use it, they have to grab the latest set of files and patches from the
jackit-devel mailing list, and apply them to jack >= 0.99.0. i will soon
put up a page where i will maintain the
72 matches
Mail list logo
