On Mon, Jul 4, 2011 at 10:23 AM, Paul Davis wrote:
> 2011/7/3 Dave Phillips :
>> Jörn Nettingsmeier wrote:
>>
>>> ... none of the audio stuff i routinely do everyday would be possible
>>> without jack.
>>
>> Amen to that.
>
> I disagree with both of you. I think what you really mean is "none of
>
2011/7/3 Dave Phillips :
> Jörn Nettingsmeier wrote:
>
>> ... none of the audio stuff i routinely do everyday would be possible
>> without jack.
>
> Amen to that.
I disagree with both of you. I think what you really mean is "none of
this would be possible without some system for interconnecting
pr
On Sunday, July 03, 2011 04:40:22 am Thomas Vecchione wrote:
> Just to clarify, the N9, and N950(The 'developer' device
> that most of the existing community really wants over
> the n9) isn't running Meego, but instead is running
> Maemo Harmattan, which is primarily Maemo, with the
> Meego develop
Jörn Nettingsmeier wrote:
... none of the audio stuff i routinely do everyday would be possible
without jack.
Amen to that.
Best,
dp
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-a
On 07/03/2011 10:14 PM, Folderol wrote:
So (excusing my ignorance) are we approaching a brick wall or is there a way
out?
i wouldn't know. if it's a brick wall, i'm perfectly happy banging my
head into it day after day, and so are my customers.
_
On 07/03/2011 07:32 PM, Paul Davis wrote:
i feel that if you spend too long reasoning about this, you will
conclude, as I have, that JACK was actually a mistake (at least in
terms of the basic framework in which to glue together different
things processing data streams). the absence of a plugin
On Sun, Jul 3, 2011 at 2:41 PM, Paul Davis wrote:
> On Sun, Jul 3, 2011 at 5:32 PM, Devin Anderson
> wrote:
>> On Sun, Jul 3, 2011 at 1:07 PM, Paul Davis
>> wrote:
>>> On Sun, Jul 3, 2011 at 3:59 PM, Devin Anderson
>>> wrote:
>>>
I'm curious about what you might have done differently if
On Sun, Jul 3, 2011 at 5:32 PM, Devin Anderson wrote:
> On Sun, Jul 3, 2011 at 1:07 PM, Paul Davis wrote:
>> On Sun, Jul 3, 2011 at 3:59 PM, Devin Anderson
>> wrote:
>>
>>> I'm curious about what you might have done differently if you knew
>>> then what you know now.
>>
>> what *should* have ha
On Sun, Jul 3, 2011 at 1:07 PM, Paul Davis wrote:
> On Sun, Jul 3, 2011 at 3:59 PM, Devin Anderson
> wrote:
>
>> I'm curious about what you might have done differently if you knew
>> then what you know now.
>
> what *should* have happened was a plugin API that as many developers
> as now use JAC
On Sun, Jul 03, 2011 at 04:20:34PM -0400, Paul Davis wrote:
> a snapshot made by (3) will not be modified by 1, 2, 4 or 5. a
> "snapshot" made by (2) will be modified by subsequent 1 or 5.
Many thanks, this was what I suspected and hoped for :-)
Maybe the text in the dialogs for (2) and (3) sho
On 3 July 2011 21:14, Fons Adriaensen wrote:
> On Sun, Jul 03, 2011 at 12:32:53PM -0400, Paul Davis wrote:
>
>> sure, which right now is not a separate function at all, but merely a
>> branch of the "finish" function. not exactly a huge amount of work to
>> split it out, but indicative of the comp
On Sun, Jul 3, 2011 at 4:14 PM, Fons Adriaensen wrote:
> Quite unrelated to all of this, I do have a question
> about Ardour's 'Save' semantics.
wrong context, but OK ...
> There are:
>
> (1) 'Save'
> (2) 'Save as'
> (3) 'Snapshot'
>
> and
>
> (4) 'Periodic safety backups' (option)
>
> and
>
>
On Sun, Jul 03, 2011 at 12:32:53PM -0400, Paul Davis wrote:
> sure, which right now is not a separate function at all, but merely a
> branch of the "finish" function. not exactly a huge amount of work to
> split it out, but indicative of the complete (and understandable)
> design assumption "ther
On Sun, 3 Jul 2011 16:07:53 -0400
Paul Davis wrote:
> On Sun, Jul 3, 2011 at 3:59 PM, Devin Anderson
> wrote:
>
> > I'm curious about what you might have done differently if you knew
> > then what you know now.
>
> what *should* have happened was a plugin API that as many developers
> as now
On Sun, Jul 3, 2011 at 3:59 PM, Devin Anderson wrote:
> I'm curious about what you might have done differently if you knew
> then what you know now.
what *should* have happened was a plugin API that as many developers
as now use JACK would have agreed to adopt.
what could have happened was some
On Sun, Jul 3, 2011 at 10:32 AM, Paul Davis wrote:
> i feel that if you spend too long reasoning about this, you will
> conclude, as I have, that JACK was actually a mistake (at least in
> terms of the basic framework in which to glue together different
> things processing data streams). the abse
2011/7/3 Paul Davis :
>
> i feel that if you spend too long reasoning about this, you will
> conclude, as I have, that JACK was actually a mistake (at least in
> terms of the basic framework in which to glue together different
> things processing data streams). the absence of a plugin API that was
On Sun, Jul 3, 2011 at 1:28 PM, Emanuel Rumpf wrote:
> - in the wiki example code, gtk_main_quit(); is called before
> jack_session_event_free( ev );
> it appears, that jack_session_event_free() will never be called ?
qtk_main_quit() has zero effect until control is returned to the main
even
On Sun, Jul 3, 2011 at 1:09 PM, Emanuel Rumpf wrote:
> SaveAndQuit (without Quit only) is not so bad, as it appears
> initially. Actually I seem to like the idea of this simplification.
> Although one has to get used to it.
>
> What I'm really missing is SaveAndClose (without application Quit !).
Further jack-session difficulties:
- some applications use a full path as jack-sessions command_line ==>
not platform independent, not at all
(amSynth vs. /usr/bin/amSynth )
- most use single character parameters in the command_line ==> bad:
-P and -p is the same on some platforms
- th
SaveAndQuit (without Quit only) is not so bad, as it appears
initially. Actually I seem to like the idea of this simplification.
Although one has to get used to it.
What I'm really missing is SaveAndClose (without application Quit !).
Restarting all applications for changing a session doesn't appe
On Sun, Jul 3, 2011 at 12:04 PM, Fons Adriaensen wrote:
> On Sun, Jul 03, 2011 at 08:10:09AM -0400, Paul Davis wrote:
>
>> the lack of quit-without-save is a decision that i was opposed to, but
>> accepted precisely because it has the potential to interfere with
>> developer's internal architectur
On Sun, Jul 03, 2011 at 08:10:09AM -0400, Paul Davis wrote:
> the lack of quit-without-save is a decision that i was opposed to, but
> accepted precisely because it has the potential to interfere with
> developer's internal architecture. most applications these days ask if
> you attempt to quit wi
On Sun, Jul 3, 2011 at 9:19 AM, Robin Gareus wrote:
> Is "quit w/o save" really needed? IMHO a smarter way would be to
> "auto-save" the session every e.g. 5 mins and add keep those as
> revisions in a repository.
if you think about it, this is also quite intrusive on application
architecture.
On 07/03/2011 03:01 PM, Paul Davis wrote:
> On Sun, Jul 3, 2011 at 8:51 AM, Robin Gareus wrote:
>
>> Every program (on un*x) can be "quit w/o save" without requiring changes
>> to the program: just send it a `kill -9` :-))
>
> if (request.type == QuitWithoutSave) {
> kill (getpid()
On Sun, Jul 3, 2011 at 8:51 AM, Robin Gareus wrote:
> Every program (on un*x) can be "quit w/o save" without requiring changes
> to the program: just send it a `kill -9` :-))
if (request.type == QuitWithoutSave) {
kill (getpid(), SIGKILL);
}
oops, you didn't reply to the ses
On 07/03/2011 02:10 PM, Paul Davis wrote:
> On Sun, Jul 3, 2011 at 7:43 AM, Fons Adriaensen wrote:
>> JSM is one of them, it's a mess
>> even in its initial form.
>
> its important to point out that this is a criticism that could be
> levelled at JACK too.
>
> your analysis was thoughtful and se
Am Sun, 03 Jul 2011 11:10:08 +0200
schrieb rosea grammostola :
> On 07/03/2011 09:44 AM, Emanuel Rumpf wrote:
> > 2011/7/2 m.wolkst...@gmx.de:
> >
> >>
> >> but i didn't agree to save the application data into the jack-session
> >> folder!
> >>
> > You really should make that a user option !
>
>
On Sun, Jul 3, 2011 at 7:43 AM, Fons Adriaensen wrote:
> JSM is one of them, it's a mess
> even in its initial form.
its important to point out that this is a criticism that could be
levelled at JACK too.
your analysis was thoughtful and sensible. as it turned out, neither
torben nor I agreed wi
On Sun, Jul 03, 2011 at 11:53:29AM +0200, rosea grammostola wrote:
>> Fons has been quite busy moving home the last weeks (not far,
>> south of Parma to north of Parma, but it's the same exercise
>> independent of distance anyway).
> Good luck with that.
Thanks ! I'm at my new place, basic life s
Hi
I have recently added jack session support to rakarrack ... I was check with
jack1 ...and session is restored perfectly even if I use a lot of rakarrack
instances with others apps but ... I have problems with jack2 ... if I use
more than one instance of rakarrack ... sometimes works
On 07/03/2011 11:58 AM, rosea grammostola wrote:
On 07/03/2011 02:19 AM, m.wolkst...@gmx.de wrote:
Next thing what would be good to have imo is a good software mixer with
JackSession support. Unfortunately non-mixer is not a good candidate
afaik, cause it changes port names. I don't know if Fo
On 07/02/2011 07:25 PM, Emanuel Rumpf wrote:
2011/7/2 rosea grammostola:
It seems to work good here. You have to disable JACK autoconnect in PHASEX
and then the connections seems to work.
Here they don't.
And phasex requires much time to start.
How does jack-session know, when an application
On 07/03/2011 02:19 AM, m.wolkst...@gmx.de wrote:
Next thing what would be good to have imo is a good software mixer with
JackSession support. Unfortunately non-mixer is not a good candidate
afaik, cause it changes port names. I don't know if Fons is still busy
with his mixer and if he has expl
On 07/03/2011 12:27 AM, Fons Adriaensen wrote:
On Sat, Jul 02, 2011 at 11:02:27PM +0200, rosea grammostola wrote:
Next thing what would be good to have imo is a good software mixer with
JackSession support. Unfortunately non-mixer is not a good candidate
afaik, cause it changes port names. I do
On Sat, Jul 2, 2011 at 4:46 PM, Niels Mayer wrote:
> Specifically, MeeGo on the Nokia N9 (
> https://flors.wordpress.com/2011/06/20/nokia-n9-state-of-the-art-of-mobile-linux-and-qt/
> ). I'm sure that it will be easier to create handheld multimedia
> applications on an in-production and widely-d
On 07/03/2011 09:44 AM, Emanuel Rumpf wrote:
2011/7/2 m.wolkst...@gmx.de:
but i didn't agree to save the application data into the jack-session folder!
You really should make that a user option !
Yep, I do agree with this. It starts to get complex again if all apps
will have there own way
2011/7/2 m.wolkst...@gmx.de :
>
>
> but i didn't agree to save the application data into the jack-session folder!
>
You really should make that a user option !
One of the main points of a session is, to keep data *together*.
So everything belonging to one session goes to one single folder.
If yo
38 matches
Mail list logo