>No, imho one of the main advantages is Qt's Signal/Slot mechanism and my=20
>current implementation has come so far that I can send and receive OSC=20
>messages with one argument (of type QVariant) via signals and slots.
i don't want to get into a toolkit war, but gtkmm has been using
SigC++ sinc
On Saturday 19 March 2005 19:12, Lars Luthman wrote:
> On Wed, 2005-03-16 at 17:39 +0100, Arnold Krille wrote:
> > Maybe we could join forces for an liblo-Qt-class?
> > Which timeframe are we talking about?
> Why a Qt class? A generic C++ implementation would probably be useful to
> lots of other p
> Syncing video playback to Ardour would be a great example of the
> usefullness of jack-transport. Unfortunately, i guess the fact
> is that the design of mplayer means it can never be a real jack
> client. Perhaps a jack client could control mplayer via its slave
> mode, for use with non-keyfram
On Sat, Mar 19, 2005 at 07:12:54PM +0100, Lars Luthman wrote:
> On Wed, 2005-03-16 at 17:39 +0100, Arnold Krille wrote:
> > Maybe we could join forces for an liblo-Qt-class?
> > Which timeframe are we talking about?
>
> Why a Qt class? A generic C++ implementation would probably be useful to
> lot
> Cut that. aRts isn't maintained anymore. KDE is heading for
> another solution and currently (kde3.4) half of the players
> in kde have their own plugin system to support different
> soundservers / outputmethods to be independent from aRts...
> It won't live longer than kde 3.5, which will hopef
On Saturday 19 March 2005 17:59, Christoph Eckert wrote:
> If your softphone should be straightforward to the user, it
> needed to support different soundsystems, and to try to
> automatically select one during start time. Here one idea in
> which order this could happen:
> * JACK
> * Arts
Cut tha
On Wed, 2005-03-16 at 17:39 +0100, Arnold Krille wrote:
> Maybe we could join forces for an liblo-Qt-class?
> Which timeframe are we talking about?
Why a Qt class? A generic C++ implementation would probably be useful to
lots of other projects too.
--
Lars Luthman
PGP key: http://www.d.kth.s
On Sat, Mar 19, 2005 at 11:29:57AM -0500, Paul Davis wrote:
> correct. SMPTE provides positional sync with a resolution of 1 SMPTE
> frame (on the order of 1/30th second) - in other words, appalling for
> audio synchronization.
each frame is divided into 80 'bits', referred to as subframes.
in ad
> For context, the app is a softphone.
Kewl.
> All linux softphones
> stink in all ways, plus none was readily adaptable to JACK.
> I, being an audio geek, would like to hook up a call to a
> JACK graph. But most people would like the thing to just
> work without hassle, hence the ALSA option (
>Sorry, the other thread idea is in order to avoid SIGIO. The thread
>would select on the audio device and drain it into a ringbuffer for the
>other thread to use.
s/select/poll/ => welcome to JACK :))
you really want to do all this work over again?
--p
>On Fri, Mar 18, 2005 at 11:34:34PM +0100, Jens M Andreasen wrote:
>> Do jack-transport support SMPTE
>> Do jack-transport support MIDI song pointer
>>
>> (guessing yes to above)
>
>actually i beleive the answer is mostly no, although perhaps
>its best to consider smpte and midi as paralle rath
Hi!
The aim is to investigate some signal which consists of main
harmonic and others with rather low level. I'd like to reject
main harmonic _and_do_not_affect_ to other harmonics. What
LADSPA plugin is the most sutable for such work?
Thanks!
Andrew
On Fri, 18 Mar 2005 at 23:53 +0100, Jens M Andreasen wrote:
> On Fri, 2005-03-18 at 08:24 -0700, Hans Fugal wrote:
>
> >
> > As I understand it, alsa can be asynchronous but it requires using SIGIO
> > which doesn't excite me. So I'd have to create another thread that
> > selects and fills a ring
On Fri, Mar 18, 2005 at 11:34:34PM +0100, Jens M Andreasen wrote:
> Do jack-transport support SMPTE
> Do jack-transport support MIDI song pointer
>
> (guessing yes to above)
actually i beleive the answer is mostly no, although perhaps
its best to consider smpte and midi as paralle rather than
14 matches
Mail list logo