On Sat, 17 Aug 2002 02:07:36 -0300
Juan Linietsky <[EMAIL PROTECTED]> wrote:
http://reduz.com.ar/legasynth
> Legasynth 0.4.1 is out.
> Legasynth is a mature app, and it's ready for professional/studio
> usage. It also features
> a frinedly userinterface for managing all presets you create, and
>
On Fri, 2002-08-16 at 14:49, Paul Winkler wrote:
> personally I've been pondering how to make a PyGame interface
> to an sfront audio engine, and do all my audio code in SAOL.
I've been thinking of this kind of thing as well. (It "hurts" to go
back from coding in SAOL to coding in C, especiall
And... at where might one pick this up?
Juan Linietsky wrote:
>Legasynth 0.4.1 is out.
>Legasynth is a mature app, and it's ready for professional/studio
>usage. It also features
>a frinedly userinterface for managing all presets you create, and even
>drum banks.
>
>LegaSynth:
>--
>LegaS
Legasynth 0.4.1 is out.
Legasynth is a mature app, and it's ready for professional/studio
usage. It also features
a frinedly userinterface for managing all presets you create, and even
drum banks.
LegaSynth:
--
LegaSynth is an old chip/synthethizer emulator. It currently uses the
ALSA seq
Forgive my ignorance, but are we referring to
http://sf.net/projects/high-res-timers/ by
any chance?
Regards,
Scott.
On 2002.08.17 05:54 Vincent Touquet wrote:
> On Fri, Aug 16, 2002 at 02:22:35PM -0400, Paul Davis wrote:
> (cut)
> >2) is cheap, the patch exists, and we should consider promo
I wonder if anyone has tried the perl DSP.pm module, or if these scripting
languages are just too slow, I just wonder if basically everything must be
done in C/C++, I have played with javasound, but it requires a large
buffer for clean playback, kinda killing any hope for decent latency. I'm
hungr
On Fri, 16 Aug 2002 14:14:02 -0400
Paul Davis <[EMAIL PROTECTED]> wrote:
>
> >We know that the ideal way of doing this is having both the
> >sequencer and the softsynth access to the same exact clock for
> >reference, then having the audio app a predefined "delay in time"
> >consisting of the fr
On Fri, 16 Aug 2002 09:40:01 -0400
Paul Davis <[EMAIL PROTECTED]> wrote:
> none of this, alas, addresses the more fundamental question of how to
> do the timing correctly. without something like the hard-timer patch,
> its more or less impossible to do MIDI sequencing correctly under
> linux.
T
On 16 Aug 2002 12:49:07 -0700, Paul Winkler wrote:
> On Fri, Aug 16, 2002 at 11:26:32AM -0700, Brian Redfern wrote:
> > Actually a physicicst in northern germany came up with a realtime python
> > binding to alsa audio:
> > http://home3.ecore.net/cafeconleche/
> > Its not complete (audio support o
On 16 Aug 2002 09:19:14 -0700, Paul Winkler wrote:
> On Fri, Aug 16, 2002 at 04:48:17PM +0200, Kasper Souren wrote:
> > The Python documentation about extending/embedding seems okay, but they don't
> > mention how to compile the .c file to get an .so file. I think it has been
> > written for exp
Paul Davis wrote:
>>Paul Davis wrote:
>>
I find that for sending MIDI to an external device, "resolution = RTC
Hz" works very well. It is a problem that a realtime audio thread
'suffocates' a RTC thread if low-latency is required, and only one
processor available. It's very hard t
> Actually a physicicst in northern germany came up with a realtime python
> binding to alsa audio:
There is also an OSS driver, and SDL/Pygame supports esd and arts output. No
promises wrt. latency or flexibility with these implementations.
I tried the python/alsa stuff but concluded that it
On Fri, Aug 16, 2002 at 02:22:35PM -0400, Paul Davis wrote:
(cut)
>2) is cheap, the patch exists, and we should consider promoting it as
> widely as the low latency patches.
(cut)
Ok, let the lobbying begin :)
v
On Fri, Aug 16, 2002 at 11:26:32AM -0700, Brian Redfern wrote:
> Actually a physicicst in northern germany came up with a realtime python
> binding to alsa audio:
> http://home3.ecore.net/cafeconleche/
> Its not complete (audio support only, no midi), but it looks like it
> works, I'm downloading
Actually a physicicst in northern germany came up with a realtime python
binding to alsa audio:
http://home3.ecore.net/cafeconleche/
Its not complete (audio support only, no midi), but it looks like it
works, I'm downloading tonight after work to give it a try, it would
certainly be easier to writ
>So we need something which handles the timing like the DirectMusic(tm) in the
>Linux kernel.
not at all. we just need very accurate scheduling, which implies
either:
1) an incredibly high timer interrupt.
OR
2) interrupts when needed.
1) costs too much on most, if not all, hardw
>Paul Davis wrote:
>
>>>I find that for sending MIDI to an external device, "resolution = RTC
>>>Hz" works very well. It is a problem that a realtime audio thread
>>>'suffocates' a RTC thread if low-latency is required, and only one
>>>processor available. It's very hard to find a clean solution i
>> >using my drum machine or hard disk recorder as the clock source.
>>
>> these devices provide a very low resolution clock, and it can't be
>> used to schedule MIDI data, only to provide a low resolution
>> positional reference.
>
> 24ppq is fine when your sequencer only schedules notes on 24p
>We know that the ideal way of doing this is having both the sequencer
>and the softsynth access to the same exact clock for reference, then
>having the audio app a predefined "delay in time" consisting of the
>fragment size. After that it's a simple matter of taking the current
>time before mixi
On Friday 16 August 2002 18:19, Paul Winkler wrote:
> http://www.python.org/doc/current/ext/building-on-unix.html
Ok. I should have carefully RTF docs :)
> or if you don't want to bother with distutils,
> I just found this in an old comp.lang.python post:
>
> INC="-I/usr/local/src/Python-2.2/Inc
Paul Davis ([EMAIL PROTECTED]):
> > What do you think the solution is? [...]
>
> the hard-timers patch or something like it needs to go into the
> kernel.
Thanks for clarifying.
> >ardour apparently outputs MIDI clock sync. [...]
>
> no, it outputs MIDI Time Code, which is an entirely dif
Paul Davis wrote:
>>I find that for sending MIDI to an external device, "resolution = RTC
>>Hz" works very well. It is a problem that a realtime audio thread
>>'suffocates' a RTC thread if low-latency is required, and only one
>>processor available. It's very hard to find a clean solution in this
On Fri, Aug 16, 2002 at 04:48:17PM +0200, Kasper Souren wrote:
> The Python documentation about extending/embedding seems okay, but they don't
> mention how to compile the .c file to get an .so file. I think it has been
> written for experienced C programmers.
http://www.python.org/doc/current/
On Fri, 16 Aug 2002 09:40:01 -0400
Paul Davis <[EMAIL PROTECTED]> wrote:
I sent a mail about this to the alsa-dev list, but didnt really get an
useful
answer.
I ran into the following problem when running my sequencer and my
sofsynth
together. Using ALSA sequencer, I can set a timestamp to the mi
> So we need something which handles the timing like the DirectMusic(tm) in
> the Linux kernel.
I would prefer not to have this in the kernel. If the kernel provides
accurate
scheduling and CLOCK_MONOTONIC then I think this can and should
be done from user-space. A driver should be able to read
C
> I find that for sending MIDI to an external device, "resolution = RTC
> Hz" works very well. It is a problem that a realtime audio thread
> 'suffocates' a RTC thread if low-latency is required, and only one
> processor available. It's very hard to find a clean solution in this
> case, but firm
So we need something which handles the timing like the DirectMusic(tm) in the Linux
kernel. How about the ALSA project, could they put this stuff there? I mean even
DirectMusic can synchronize it's master clock to audio clock, it surely must be
possible also in Linux? Funny someone mentioned th
On Friday 09 August 2002 00:39, Andrew W. Schmeder wrote:
> However these days I recommend Python with Numeric/Scientific/SciPy
> extensions over Octave (and over Matlab). In addition to Python's
> unquestionably superior language support and library integration, Numeric
> offers some extra featu
>I find that for sending MIDI to an external device, "resolution = RTC
>Hz" works very well. It is a problem that a realtime audio thread
>'suffocates' a RTC thread if low-latency is required, and only one
>processor available. It's very hard to find a clean solution in this
why not just run the
>I agree, however HZ=1000 should be usable for MIDI even without patches
>for improved scheduling. I believe HZ=1000 is in 2.5?
its usable, but its still not "correct".
right now, you can use RTC Hz = 1024 for the same effect, though that
is slightly even less "correct".
--p
>> none of this, alas, addresses the more fundamental question of how to
>> do the timing correctly. without something like the hard-timer patch,
>> its more or less impossible to do MIDI sequencing correctly under
>> linux. of course, you can do it "well enough" with existing
>> mechanisms, but t
Paul Davis wrote:
>none of this, alas, addresses the more fundamental question of how to
>do the timing correctly. without something like the hard-timer patch,
>its more or less impossible to do MIDI sequencing correctly under
>linux. of course, you can do it "well enough" with existing
>mechanis
> >Haven't written anything using MIDI and JACK (or LADSPA), but would it be
poss
> >ible to have a such system as with Cubase where the softsynths are
plugins whi
> >ch receive time-stamped MIDI events (time-stamp is an offset from the
block be
> >ginning in samples).
Either this (use audio samp
Paul Davis ([EMAIL PROTECTED]):
> none of this, alas, addresses the more fundamental question of how to
> do the timing correctly. without something like the hard-timer patch,
> its more or less impossible to do MIDI sequencing correctly under
> linux. of course, you can do it "well enough" with
On Fri, Aug 16, 2002 at 12:23:05PM +0100, Bob Ham wrote:
> On Fri, 2002-08-16 at 11:31, Tobias Ulbricht wrote:
> > where has tolerance, hospitality and an unbiased attitude towards others
> > gone that this list had so far?
>
> That's a good question. There seems to be a lot of negativity float
>Haven't written anything using MIDI and JACK (or LADSPA), but would it be poss
>ible to have a such system as with Cubase where the softsynths are plugins whi
>ch receive time-stamped MIDI events (time-stamp is an offset from the block be
>ginning in samples). The MIDI-through events that come in
I think it's quite incredible that he has done all the work himself
including the docs and produced such a slick looking program.
However count me out of the list for pdf writers. I can't stand them. :)
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www
Haven't written anything using MIDI and JACK (or LADSPA), but would it be possible to
have a such system as with Cubase where the softsynths are plugins which receive
time-stamped MIDI events (time-stamp is an offset from the block beginning in
samples). The MIDI-through events that come into s
On Fri, Aug 16, 2002 at 12:31:22PM +0200, Tobias Ulbricht wrote:
>Rediculus!
>where has tolerance, hospitality and an unbiased attitude towards others
>gone that this list had so far?
ACK.
I have been upset by some messages on this list too.
I didn't want to react as it seemed like
*an utter wast
On Fri, Aug 16, 2002 at 11:18:54AM +0200, Ingo Oeser wrote:
(cut)
>Price: We got them donated, but they cost about half a car, if
> you get them new, we have been told.
That would be a showstopper for me :)
1000$ is one thing, but I cannot afford 2500$+
It seems interesting though.
I'll let y
On Fri, 2002-08-16 at 11:31, Tobias Ulbricht wrote:
> where has tolerance, hospitality and an unbiased attitude towards others
> gone that this list had so far?
That's a good question. There seems to be a lot of negativity floating
about for some reason. I'd like it go away.
--
Bob Ham: [EMA
I can only agree.
Now if we PLEASE could leave this subject, I can see nothing good coming out of
this discussion. We are different, we work different, we live different, that is
that. If you are interested in politics, try a different mailinglist, join a
political party or whatever.
Regards,
I'm a bit shocked by the attitudes that have been displayed here too, and it's
unusual to see on this list.
Linux was started for fun, please don't forget that.
> Hey Brian and others.
>
> On Thu, 15 Aug 2002, Brian Redfern wrote:
>
> > I didn't mean to say anyone has to do anything, but its a
>perpetrators. What would be helpful is not just the sites with links to
>linux audio apps, but maybe a site that would be a resource for learning
>c/c++ dsp coding under linux. I for one have not had the benefit of a
there is nothing special about linux when it comes to writing dsp code.
there
Hey Brian and others.
On Thu, 15 Aug 2002, Brian Redfern wrote:
> I didn't mean to say anyone has to do anything, but its a lot easier to
> complain about someone else's code (and yeah, he did bring it on to
> himself by not reading up about linux culture first) than it is to roll
Why don't yo
At Fri, 16 Aug 2002 07:25:03 +1000,
Erik de Castro Lopo wrote:
>
> On Thu, 15 Aug 2002 11:06:33 -0400
> Dave Phillips <[EMAIL PROTECTED]> wrote:
>
> > Hi, Conrad:
> >
> > A quick question: I have libsndfile 0.0.28 installed here, I need it
> > because Ardour doesn't yet utilize 1.0.0. Is ther
--- Brian Redfern <[EMAIL PROTECTED]> wrote: > I
[...]
> I for one have not had
> the benefit of a
> computer science education, so all my knowlege comes
> from hardcore
> bootstrapping. I'm sure many people would like to
> help, but simply lack
> the math background to be able to understand
> c
On Wed, Aug 14, 2002 at 09:24:31AM +0200, Vincent Touquet wrote:
> >We would write drivers for exactly the 4 modes described above,
> >so the DSP could actually just a kind of plugin to your sound
> >architecture of choice.
> Doesn't the fact that the Chameleon
> sits in a rack defeat this purpose
48 matches
Mail list logo
