Re: [LAD] A Cathedral in your backyard

[torbenh]

On Wed, Apr 25, 2007 at 07:00:51PM +0200, Jens M Andreasen wrote:
> On Wed, 2007-04-25 at 09:40 -0700, Xavier Amatriain wrote:
> > On Wed, 2007-04-25 at 18:41 +0200, Joern Nettingsmeier wrote:
> > > granted. but a bass drum does have hi-frequency cues as well. the 
> > > interesting thing about that drum was that there was an insane amount
> > > of 
> > > sound energy in a very small space, with very few and quite soft
> > > phantom 
> > > images.
> > 
> > You are right, it is amazing how well you can "distribute" energy using
> > these arrays.
> > 
> 
> J?rn, did you feel the impact of the low frquecies in your belly?

thats what its all about ;)
and dont tell me, you can do this with some 3 subwoofers.
we are talking about hearing with the skin here. (and of course you can
localise the bass with the skin)

perhaps this also explains, why these kind of demonstrations are not
public.

> 
> /jens
> -- 
> 
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

Re: [LAD] A Cathedral in your backyard

[torbenh]

On Wed, Apr 25, 2007 at 10:02:29AM +0200, Fons Adriaensen wrote:
> On Wed, Apr 25, 2007 at 09:15:35AM +0200, Jens M Andreasen wrote:
> 
> > What I think would be possible as an experiment though (without
> > involving a budget the size of the Pope or TU-Berlin), is to place a
> > large amount of uniform speakers in a circle and then feed them with the
> > same monophonic signal. If everything works as expected, it should then
> > appear like the sound emerges from the center of the circular array of
> > speakers.
> > ...
> > Would that work? 
> 
> It probably would, *if* you can get all speakers to be exactly in phase
> over the entire frequency band. This will be difficult at HF, and having
> part of the range  not focused will destroy the effect and identify the
> radios as the source of the sound. 
> 
> You don't even need a full circle or sphere. I'm currently involved in
> a project using an array of 228 speakers / 64 channels suspended as a 3m
> diameter 'chandelier' from the ceiling. It will create sound sources moving
> above and around the listener's head. 

are you writing your own software to do this ?
mine still needs some minor fixes to handle this sort of setup.

how are the speakers connected to the channels ?

> 
>  
> FA
> 
> Follie! Follie! Delirio vano ? questo !
> 
> 
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

Re: [LAD] [ANN] LV2 beta3

[torbenh]

On Thu, May 10, 2007 at 09:41:49AM +0200, Thorsten Wilms wrote:
> On Wed, May 09, 2007 at 07:14:05PM -0400, Thomas Vecchione wrote:
> 
> > >Either way, everything just works (or not) as it should.
> > >
> > 
> > Not to someone not familiar with the internals of how LV2 works.  As an 
> > example(I hate to bring up) how many people do you think could tell you 
> > how the ineternals of a VST program work.  Heck how many do you think 
> > have an even basic idea of computer programming, much less tell you the 
> > above.
> 
> What has understanding internals to do with this?
> All that will need to be understood is that is-an-LV2 is not 
> enough to describe a plugin or host.
> 
>  
> > Again for a programmer and specifically someone familiar with how LV2 
> > works, that is fine.  For someone that has no concept of programming, 
> > and just want something that works when(To them) it is supposed to, this 
> > is a huge screwup that can be fixed relatively easily to be honest.
> 
> Fixed relatively easy how?
> 
> 
> > Once again, this is not about me I am mentioning this.  This is for the 
> > half dozen people(As of right now, obviously not counting those that I 
> > have gotten used to linux and how things work that might start again) 
> > that still come to me wondering why something doesn't 'just work'.
> 
> Do you propose to not have a plugin standard that can be extended for 
> various current and possible future needs to avoid some possible user 
> confusion?
> 
> Shall all hosts be forced to support all extensions available so 
> that a sample editor would have to "support" MIDI plugins?

the problem will be rather: why has this plugin a GUI in ardour and
ingen and not in qtractor.

while this other plugin has a gui in qtractor and non in ardour and
ingen. 

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

Re: [LAD] [ANN] LV2 beta3

[torbenh]

On Thu, May 10, 2007 at 11:44:54PM +0200, Fons Adriaensen wrote:
> On Thu, May 10, 2007 at 03:58:25PM +0100, Steve Harris wrote:
> 
> > I don't support it unless someone has a representation issue. You're  
> > not like to see if (fs == 44100) anyway, and if you did you'd want to  
> > hedge a bit: if (fs > 44090 && fs < 44110). If you have to write if  
> > (fs_num / fs_denom == 44100) then things are bit dodgy anyway.
> 
> Let me state once and for all, even it will not gain me any popularity:
> 
>   Anyone who thinks that writing a range check on a fraction A/B is too
>   difficult is very probably completely incompetent and should not waste
>   his/her time trying to write audio DSP code for a plugin.

Anyone who refuses to write LV2 extensions has a bad taste.
this is about aesthetics. 

we all love the sound, but look:


void Ladspa_Moogvcf2::runproc (unsigned long len, bool add)
{
int   k;
float *p0, *p1, *p2, *p3, *p4;
float c1, c2, c3, c4, c5;
float g0, g1, r, dr, w, dw, x, t;

p0 = _port [0];
p1 = _port [1];
p2 = _port [2] - 1;
p3 = _port [3] - 1;
p4 = _port [4] - 1;
g0 = exp2ap (0.1661 * _port  [5][0]) / 2;
g1 = exp2ap (0.1661 * _port [10][0]) * 2;
if (add) g1 *= _gain;

c1 = _c1 + 1e-6;
c2 = _c2;
c3 = _c3;
c4 = _c4;
c5 = _c5;
w = _w; 
r = _r;

do
{
k = (len > 24) ? 16 : len;
p2 += k;
p3 += k;
p4 += k;
len -= k;

t = exp2ap (_port [7][0] * *p3 + _port [6][0] + *p2 + 10.71) / _fsam;
if (t < 0.8) t *= 1 - 0.4 * t - 0.125 * t * t;
else 
{
t *= 0.6; 
if (t > 0.92) t = 0.92;
}
dw = (t - w) / k;

t = _port [9][0] * *p4 + _port [8][0];
if (t > 1) t = 1;
if (t < 0) t = 0;
dr = (t - r) / k;  

while (k--)
{
w += dw;
r += dr;

x = -4.5 * r * c5 + *p0++ * g0 + 1e-10;
//  x = tanh (x); 
x /= sqrt (1 + x * x);
c1 += w * (x  - c1) / (1 + c1 * c1);
c2 += w * (c1 - c2) / (1 + c2 * c2);
c3 += w * (c2 - c3) / (1 + c3 * c3);
c4 += w * (c3 - c4) / (1 + c4 * c4);

if (add) *p1++ += g1 * (c4);
else *p1++  = g1 * (c4);
c5 += 0.5 * (c4 - c5);
}
}
while (len);

_c1 = c1;
_c2 = c2;
_c3 = c3;
_c4 = c4;
_c5 = c5;
_w = w;
_r = r;
}



you are IMO disqualified from aestetics discussions :)




-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

Re: [LAD] Controller images

[torbenh]

On Thu, May 24, 2007 at 09:48:39AM +0200, Christian wrote:
> 
> Wow, thank you very much!
> Well I think it is worth to have a look at blender.
> As you mentioned the code based rendering: All images are stored in a
> xml file so that everyone using my gui can exchange them to create his
> own style. So I don't think that a rendering approach would be that useful.
> Christian

mhmh... saving the knob anims in an xml file is too much hassle IMO.
my first animated knob was based on a gif animation.

now i resorted to png because of the alpha, and gif being bad...
is the patent hassle gone now ?

i have put all animation phases into one png.
now the problem is, that we need one integer as metadata, to find the
number of animation phases.

Then all height and width of the knob images could be calculated.
i know, that there are fields for metadata inside a png.

Is it possible to set and get them with GdkPixbuf ?
we should try to agree on something.



-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

Re: [LAD] Controller images

[torbenh]

On Thu, Jun 07, 2007 at 08:55:59PM +0100, pete shorthose wrote:
> On Thu, 2007-06-07 at 00:32 +0100, pete shorthose wrote:
> 
> > with my own galan knob ancestor,
> 
> shit. invert that last bit. sorry torben. /(>_<)\

huh ? :)
nevermind.

oki.. 
so some .ini style syntax, easily parsed with GKeyFile

perhaps some sections for different backgrounds ?
i noticed, that the current galan knobs dont look so nice on a black bg.

the rendered shadows are alpha, but they are grey.
so the shadow actually lights the background.

keys:
png_filename
width
height
num_pixmaps

any other thoughts ?
> 
> 
> pete
> 
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

Re: [LAD] Controller images

[torbenh]

On Wed, Jun 13, 2007 at 04:33:27PM +0100, pete shorthose wrote:
> On Mon, 2007-06-11 at 06:32 +0200, [EMAIL PROTECTED] wrote: 
> > On Thu, Jun 07, 2007 at 08:55:59PM +0100, pete shorthose wrote:
> > > On Thu, 2007-06-07 at 00:32 +0100, pete shorthose wrote:
> > > 
> > > > with my own galan knob ancestor,
> > > 
> > > shit. invert that last bit. sorry torben. /(>_<)\
> > 
> > huh ? :)
> > nevermind.
> 
> moving swiftly along then... :]
> 
> > oki.. 
> > so some .ini style syntax, easily parsed with GKeyFile
> 
> gets my vote. i hadn't thought of GKeyFile.
> 
> > i noticed, that the current galan knobs dont look so nice on a black bg.
> >
> > the rendered shadows are alpha, but they are grey.
> > so the shadow actually lights the background.
> 
> this is a tricky one. you probably see that because the knob anim
> was created with unsuitable rendering options. 

perhaps :) a friend of mine rendered it under windows...
no suitable rendering options there.

> 
> there are also two different cases here. animations for use against a
> dynamic
> themed bg and animations created for use against a static (pixmap or
> themed) bg. 
> if you specify a static bg then the makeup of rendered shadows doesn't
> matter
> much as you can see right away how well they work. but for use with gtk
> themes
> you need black shadows tempered by the alpha (not grey scale or colour
> tinted
> shadows) in order to get consistently good results across all possible
> colours.
> 
> > perhaps some sections for different backgrounds ?
> 
> if you want then i won't object but if i understand you
> correctly then it's still going to look powerful ugly on a dark 
> theme anyway right?
> 
> not only would i encourage people to (re)render their animations
> with black shadows and alpha but i'll personally commit to doing
> so for anyone who asks (where possible).
> 
> > 
> > keys:
> > png_filename
> > width
> > height
> > num_pixmaps
> 
> i'd suggest using frames instead of num_pixmaps. it makes sense in the
> context of an animation and most of the gtkknob implementations seem to
> have settled on drawing from an offset within the original image rather
> than chopping it up into separate images and putting them into a GList. 

ack. starting reimplementation using gob.

> 
> > 
> > any other thoughts ?
> 
> a version tag for future extension of the spec without screwing up the
> legacy?
> 
> WRT the galan knob animation, is the source available? i asked you a
> year or 2 back and i can't remember why it wasn't then. nor can i
> remember what it was created with, but if it was blender, look in the
> scene tab, in the render block and at the bottom, select  the "Premul"
> option and rerender the sequence. the background and shadows should
> appear black in the render window. see if that helps with the shadows.
> if you can get me the source then i'd be happy to do it too.

it lightwave and photoshop.

> 
> cheers,
> pete.
> 
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

Re: [LAD] intergrating osc

[torbenh]

On Sat, Jul 28, 2007 at 11:24:36AM +1000, Loki Davison wrote:
> On 7/27/07, Patrick Shirkey <[EMAIL PROTECTED]> wrote:
> > Arnold Krille wrote:
> > >
> > >
> > > Oh, another thing. If you use Qt4 for the Gui/Toolkit, there is ofqf (OSC
> > for
> > > Qt4, http://www.arnoldarts.de/drupal/?q=node/573) which encapsulates osc
> > over
> > > udp in QObjects without external libraries (except for libofqf:).
> > >
> > > Have a nice day,
> > >
> >
> > I'll check it out for ideas but I'm already using gtk2 so I really need
> > to understand binding to a gtk2 fader.
> >
> > Does jamin allow for the faders to be controlled by osc or is it just
> > the scenes?
> >
> > Cheers.
> >
> 
> 
> Yay for plugs... ;) We have recently added a widget to phat for just
> this case. PhatRange. You can hook it up to monitor a variable or
> update it with osc. Plus the new fan sliders are damn sexy x composite
> things ;P.

huh ? do you mean the PhatAdjustment ?


> 
> Loki
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

Re: [LAD] Re: Audio over Cat5

[torbenh]

On Mon, Oct 01, 2007 at 08:25:47PM +0200, Arnold Krille wrote:
> Am Montag, 1. Oktober 2007 schrieb Doug Helbling:
> > Regarding this whole audio over Cat5 thread, do we actually understand what
> > the objective is of this exercise / project?  Is the original authors use
> > of terminology such that we know what is actually supposed to be achieved?
> 
> > Sorry, I digress.  So tell me again ... what is the real goal of this
> > project?
> 
> As far as I got it the task/question was to use the Cat5-cables for analog 
> music-signals (which is not a problem) and have a digital (modified or 
> unmodified) WRT-router route the music to different ports or to produce the 
> audio-signals on its ethernet-ports (which is a problem, i.e. not possible).
> 

heh... with proper programming we could generate a DSD stream on the
ethernet output... even with GHz samplerate...

/me hides.



> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev


-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

Re: [LAD] vectorization

[torbenh]

On Wed, Apr 16, 2008 at 04:46:10PM +0200, Jens M Andreasen wrote:
> Benchmarking mixdown (no coeff):
> pure C++: 100 ms
> ASM SSE : 140 ms
> GCC vector extensions   : 120 ms
> 
> Benchmarking mixdown (WITH coeff):
> pure C++: 120 ms
> ASM SSE : 150 ms
> GCC vector extensions   : 170 ms
> 
> One more time for those who missed it the first time, this time
> commenting out everything but 'pure cpp w coff':
> 
> Benchmarking mixdown (WITH coeff):
> pure C++: 120 ms <-- bloody murder!

hmm.. perhaps i should upgrade my gcc...

on the vector extension:

you should not use it. use xmmintrin.h which even exists on MSVC to
make code compatible... however altivec is not supported then.


> 
> 
> 
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] FW: [piksel] The future of videojack ?

[torbenh]

On Wed, May 07, 2008 at 01:41:30AM +0300, Nedko Arnaudov wrote:
> Juuso Alasuutari <[EMAIL PROTECTED]> writes:
> 
> > /*
> >   * Set the video frame rate to num1/num2
> >   */
> > int
> > jack_set_video_rate (jack_client_t  *client,
> >   jack_nframes_t  num1,
> >   jack_nframes_t  num2);
> 
> I think we should have this as part of control API instead. Unless we
> allow changing of sample rate on-the-fly too.

@salsaman: is it necessary to change the rate ?

> 
> > /*
> >   * Set the video processing callback function
> >   */
> > int
> > jack_set_video_callback (jack_client_t   *client,
> >   JackProcessCallback  video_callback,
> >   void*arg);
> 
> I think we could reuse audio process callback.

no. video is using much more cpu time per process callback.
at a lower frequency.

30Hz vs. 44100/128 = 344.5Hz

So video needs to be done in a separate thread.
please salsaman enlighten us how you do the sync currently

i know that your patch is small and just works, but it has it
weaknesses. And while you fork, please consider this, so we can merge
at some point. Otherwise we would end with 2 different APIs.
> 
> > /*
> >   * Get the number of frames in a video port buffer
> >   */
> > jack_nframes_t
> > jack_video_get_frame_count (void *port_buffer);

i dont think there would be more than one frame per process callback.
so this call is not necessary in my opinion.

> >
> > /*
> >   * Get a frame from a video port buffer
> >   */
> > int
> > jack_video_get_frame (jack_video_frame_t *frame,
> >void   *port_buffer,
> >jack_nframes_t  event_index);

i think there should just be 2 jack_position_t in jack_client_t
and jack_video_transport_query()



-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] RME PCI Express card drivers

[torbenh]

On Wed, Oct 15, 2008 at 12:11:35PM -0400, nescivi wrote:
> Hiho,
> 
> On Tuesday 14 October 2008 13:55:33 Joern Nettingsmeier wrote:
> > Fons Adriaensen wrote:
> > > Hello all,
> > >
> > > Could someone confirm / deny the availability of
> > > fully working drivers for the following:
> > >
> > > http://www.rme-audio.de/en_products_hdspe_madiface.php
> > > http://www.rme-audio.de/en_products_hdspe_expresscard.php
> > >
> > > I hear rumours that these are / may be available but
> > > would like to be 100% sure before planning to use them
> > > in a future project.
> >
> > iirc the wfs folks at tu berlin are using those - maybe you could get in
> > touch with them (contact me off-list for addresses). or maybe marije
> > reads this and chimes in..?
> 
> yes, we used some of those, though not the express cards I think.
> I think out of 16 or so, we had to send one back for malfunctioning; but I'm 
> not sure...
> I bcc'ed the rest of the team (Simon, Torben, Thilo), who dealt more with the 
> actual technical testing and solving problems occured. They can probably say 
> something more accurate.

yes. it wasnt express cards iirc. they were not available at that time.
Thats why i did not answer.

one was defect. and 3 madi-adat bridges have
already been exchanged. 


> 
> sincerely,
> Marije

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] ALSA doumentation

[torbenh]

On Sun, Nov 16, 2008 at 11:41:49PM +0100, Fons Adriaensen wrote:
> On Mon, Nov 17, 2008 at 12:14:32AM +0200, Hannu Savolainen wrote:
> 
> > Instead this kind of monitoring can be given to a dedicated program (if 
> > a simple shell script cannot do it). This keeps the actual application 
> > clean and reduces the risk that it doesn't work with a MADI card from 
> > some other manufacturer.
> 
> That is exactly what I'm doing, and I have already told you
> at least three times. That 'dedicated program' is still _an
> application_. And no, it can't be 'a simple script' it is
> doing a lot more than you can imagine - including configuring
> a lot of external hardware, sometimes directly, sometimes by
> talking to daemons on other machines, etc. etc.
> 
> It doesn't have to work with any other card. We are relying
> on the functionality of very specific external hardware anyway.
> Unless you know a replacement for e.g. and RME ADI648, and you
> can 'abstract' both this and the ADI648 to the same remote
> control API without any loss of functionality.

considering, that you already have a solution for the problem, posted by
Clemens Ladish, this discussion is just for fun, right ?

please continue, reading this thread is making my day since 3 days :)

i have a question:
is the sync resetting a bug in alsa ?
does anybody have an interest in an ALSA bug getting fixed ?


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[LAD] IM like GUI for netjack

[torbenh]

hi...

now that the backend is mostly done, i am thinking about
a GUI for netjack.

i already found gtknetsource.py on my HD, i started mucking
with that some months ago.
i plan to extend that thingy now.

but setting up the connection, and getting IP addresses
of users is still a PITA.
i am thinking along the lines of an IM like thing, 
based on jabber.

i am not seeing good options to making this available
in the various IM clients. 
thats why i would rather like to have modified jabberd running
on jackaudio.org or at the consortium servers.

it would not support chatting or stuff.
only show who is online. and if a session is running.
it would only make the IP of a user available when he agrees,
to open session... blabla... security.

so basically you click on your buddy, to open a session.
buddy agrees.
IP of buddy is transmitted. tool measures connection.
provides you with some options.
ie compression ratio, number of channels, latency, who is master ?

and starts the netjack session.

thoughts ?


-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] IM like GUI for netjack

[torbenh]

On Sun, Nov 30, 2008 at 12:27:41PM -0500, nescivi wrote:
> On Saturday 29 November 2008 23:50:32 [EMAIL PROTECTED] wrote:
> > hi...
> >
> > now that the backend is mostly done, i am thinking about
> > a GUI for netjack.
> >
> > i already found gtknetsource.py on my HD, i started mucking
> > with that some months ago.
> > i plan to extend that thingy now.
> >
> > but setting up the connection, and getting IP addresses
> > of users is still a PITA.
> > i am thinking along the lines of an IM like thing,
> > based on jabber.
> >
> > i am not seeing good options to making this available
> > in the various IM clients.
> > thats why i would rather like to have modified jabberd running
> > on jackaudio.org or at the consortium servers.
> >
> > it would not support chatting or stuff.
> > only show who is online. and if a session is running.
> > it would only make the IP of a user available when he agrees,
> > to open session... blabla... security.
> >
> > so basically you click on your buddy, to open a session.
> > buddy agrees.
> > IP of buddy is transmitted. tool measures connection.
> > provides you with some options.
> > ie compression ratio, number of channels, latency, who is master ?
> >
> > and starts the netjack session.
> >
> > thoughts ?
> 
> Does irclib for python help?
> Creates a python irc client, which you can then have only the options you 
> propose.
> Not jabber based though.

this might be a very good alternative. 
one would need to register a second nick on freenode for this i guess.

it would still not be easy to detect the IP of a peer, if he was using a
cloak. i basically want to expose IP only if user agrees.
and detecting IP from inside NAT is not trivial.
not sure how i should tacke this. i there some service out there,
which can tell me my IP if i open a TCP connection to it ?

if you have a solution for this, irc would become my choice i guess ;D




-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] IM like GUI for netjack

[torbenh]

On Sun, Nov 30, 2008 at 10:01:23PM +0200, Stefan Kost wrote:
> [EMAIL PROTECTED] schrieb:
> > hi...
> > 
> > now that the backend is mostly done, i am thinking about
> > a GUI for netjack.
> > 
> > i already found gtknetsource.py on my HD, i started mucking
> > with that some months ago.
> > i plan to extend that thingy now.
> > 
> > but setting up the connection, and getting IP addresses
> > of users is still a PITA.
> > i am thinking along the lines of an IM like thing, 
> > based on jabber.
> > 
> > i am not seeing good options to making this available
> > in the various IM clients. 
> > thats why i would rather like to have modified jabberd running
> > on jackaudio.org or at the consortium servers.
> > 
> > it would not support chatting or stuff.
> > only show who is online. and if a session is running.
> > it would only make the IP of a user available when he agrees,
> > to open session... blabla... security.
> > 
> > so basically you click on your buddy, to open a session.
> > buddy agrees.
> > IP of buddy is transmitted. tool measures connection.
> > provides you with some options.
> > ie compression ratio, number of channels, latency, who is master ?
> > 
> > and starts the netjack session.
> 
> telepathy and tubes? jokosher imho has/had a prototype in python for some
> collborative editing.

gabble has no implementation of UDP tubes yet.
haze does not even have any tube support yet.

i will reconsider, when we are there.

its also not clear to me, how i should add my connection type into
the telepathy system without writing my own connection manager.

and i dont think clients would autodetect the new connection type
anyways. 

I would be happy if you prove me wrong, because just writing a
dbus component wrapping some popen calls, would be the easiest
way of doing things.


with irclib, or some jabber equivalent i guess this stuff would
be around 200-300 lines of python code added to the current
gtknetsource.py 

re tubes:
i am (just a little bit) concerned how much additional jitter,
a non SCHED_FIFO reflector would add to the mix on a higly loaded system.


-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] IM like GUI for netjack

[torbenh]

On Sun, Nov 30, 2008 at 10:45:49PM -0500, nescivi wrote:
> Hiho,
> 
> On Sunday 30 November 2008 22:32:10 [EMAIL PROTECTED] wrote:
> > On Sun, Nov 30, 2008 at 12:27:41PM -0500, nescivi wrote:
> > > On Saturday 29 November 2008 23:50:32 [EMAIL PROTECTED] wrote:
> > > > hi...
> > > >
> > > > now that the backend is mostly done, i am thinking about
> > > > a GUI for netjack.
> > > >
> > > > i already found gtknetsource.py on my HD, i started mucking
> > > > with that some months ago.
> > > > i plan to extend that thingy now.
> > > >
> > > > but setting up the connection, and getting IP addresses
> > > > of users is still a PITA.
> > > > i am thinking along the lines of an IM like thing,
> > > > based on jabber.
> > > >
> > > > i am not seeing good options to making this available
> > > > in the various IM clients.
> > > > thats why i would rather like to have modified jabberd running
> > > > on jackaudio.org or at the consortium servers.
> > > >
> > > > it would not support chatting or stuff.
> > > > only show who is online. and if a session is running.
> > > > it would only make the IP of a user available when he agrees,
> > > > to open session... blabla... security.
> > > >
> > > > so basically you click on your buddy, to open a session.
> > > > buddy agrees.
> > > > IP of buddy is transmitted. tool measures connection.
> > > > provides you with some options.
> > > > ie compression ratio, number of channels, latency, who is master ?
> > > >
> > > > and starts the netjack session.
> > > >
> > > > thoughts ?
> > >
> > > Does irclib for python help?
> > > Creates a python irc client, which you can then have only the options you
> > > propose.
> > > Not jabber based though.
> >
> > this might be a very good alternative.
> > one would need to register a second nick on freenode for this i guess.
> >
> > it would still not be easy to detect the IP of a peer, if he was using a
> > cloak. i basically want to expose IP only if user agrees.
> > and detecting IP from inside NAT is not trivial.
> > not sure how i should tacke this. i there some service out there,
> > which can tell me my IP if i open a TCP connection to it ?
> >
> > if you have a solution for this, irc would become my choice i guess ;D
> 
> Hmm... not really.
> Although.. sk wrote a http-tunnel for a project of ours once in ruby, to 
> tunnel osc messages to the outside world, so I could control a remote 
> scsynth, regardless of firewalls, that may be in between.
> But it required a server running a host script, which connected the tunnels.

TCP is nono.
netjack handles packet loss now. you dont even hear it with celt.

we should start talking about a wireless netjack soundcard.
i bet you have some use for that ;)
celt is ported to ARM.
and even support non-fpu.




> It's a bit convoluted, and may send audio streams around with some detour, 
> depending where the server is, and where the participants are.
> But I'm sure linuxaudio.org would be eager to give some bandwidth ;)

no detours also. they add unnecesary latency and jitter.
we have the possibility for 10ms latency netjack on dfn.
why sacrifice with a tour through the states ? :)



> 
> Maybe our LAC streamteam has some brilliant idea how to do this...
> 
> sincerely,
> Marije
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] IM like GUI for netjack

[torbenh]

On Mon, Dec 01, 2008 at 02:06:30PM +0100, Joern Nettingsmeier wrote:
> >>
> >> if you have a solution for this, irc would become my choice i guess ;D

hmmm... i have a solution now: http://checkip.dyndns.org/

> > 
> > Hmm... not really.
> > Although.. sk wrote a http-tunnel for a project of ours once in ruby, to 
> > tunnel osc messages to the outside world, so I could control a remote 
> > scsynth, regardless of firewalls, that may be in between.
> > But it required a server running a host script, which connected the tunnels.
> > 
> > It's a bit convoluted, and may send audio streams around with some detour, 
> > depending where the server is, and where the participants are.
> > But I'm sure linuxaudio.org would be eager to give some bandwidth ;)
> > 
> > Maybe our LAC streamteam has some brilliant idea how to do this...
> 
> this part of the lac streamteam must confess it doesn't have the
> faintest... which may partly be attributed to sushi deprival syndrome.
> 
> even though i hosted stefan's nat-piercing script for one of marije's
> projects, i never bothered to find out how it works... i guess it's a
> reflector that actually bounces the data back and forth.
> 
> i'm very sure that's not what you want for a netjack connection if you
> care for latency. plus you would burn huge amounts of bandwidth for
> basically nothing.

yep i dont want a reflector at all.


> the way i see it, if you want to netjack between two natted hosts,
> there's no easy way around port forwardings on both ends. which is fine

i dont want to get around port forwarding.
there is still the possibility to use UPNP to open the
port. anybody knows a library or code fragment for this ?
it would at least provide for randomized port numbers.
(If your router supports it... mine does, but i deactivated it ;S

> imho, since we are not competing with skype here, are we?

hmmm... i guess skype is not competing with us ;)
we are providing N channel support, midi transport,
low-latency lan operation. A musical codec...
transport synchronisation.

hehe :)
i need to research the possibility for cloud DSPing :D
ie rent your lexicon to other studios... lol.


> for the simple case (both end points have real ip addresses), some
> simple directory script (such as the icecast streamer list) might
> suffice, but the cool thing about the jabber idea is you can ssl it and
> maybe also use it to agree on a login procedure without having to post
> your ip (and hence, your open netjack port) for all the world to see.

yes. this is my intent.
now with the possibility to detect own IP i can decide between irc or
jabber. i dont even need to modify jabberd. 
And irc would still require cloaks to hide ips. so i guess i will go
with jabber. 

jabber already has buddy list etc implemented, and i dont need to think
about this.

Paul seems to also like the idea. the problem might only be, that
dreamhost prohibits irc like services. But this is just a presence
service. 

> 
> (btw, torben, great to hear from you again! do get in touch if you ever
> need a crashpad in essen.)

sure. but no trips planned.

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] IM like GUI for netjack

[torbenh]

On Tue, Dec 02, 2008 at 10:36:18AM +0100, Sebastian Moors wrote:
> [EMAIL PROTECTED] wrote:
> > hi...
> >
> >
> > but setting up the connection, and getting IP addresses
> > of users is still a PITA.
> > i am thinking along the lines of an IM like thing, 
> > based on jabber.
> >
> > i am not seeing good options to making this available
> > in the various IM clients. 
> > thats why i would rather like to have modified jabberd running
> > on jackaudio.org or at the consortium servers.
> >
> >
> > and starts the netjack session.
> >
> > thoughts ?
> >   
> Jabber would be a fine choice. You could use the xmpppy library and 
> write a small client which runs on your system and talks to other 
> clients with a predefined ascii or xml
> protocol. No need to hack the server, imho. The data can be wrapped in 
> the jabber messages. I could give a helping hand here if someone wants 
> to implement this app since i wrote some bots and a xmpppy tutorial 2 
> years ago. 

ok... would be apreciated. I am gonna implement this.

but i am currently trying to fix netjack for the case,
where packet loss is around 50% ie. link bandwidth is not
enough.

in fact i was thinking about using xmpppy.


-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] IM like GUI for netjack

[torbenh]

On Tue, Dec 02, 2008 at 11:01:29PM -0700, Eric Shattow wrote:
> If I may suggest, why go to all of this trouble?
> 
> Just make a client that registers with a webpage, ala ninjam.  (For those of
> you not hip to ninjam, it is a collaborative jam-session program and each
> instance can "phone home" to show the user's presence on a webpage).

i only know the linux ninjam client.
added jack support to it :)

well... i find it MUCH more work to create a website and stuff,
then just using xmpppy.
With the website i would also expose users IP to ANYONE.
i am not very comfortable with this.

i would like to ask the user before handing out his IP to someone.


> 
> In the case of local networks, advertise with avahi / mdns and be done. No
> need to attach to an IM service or XMPP.

avahi is planned.



-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] JACK for openSUSE 11.0 x86_64

[torbenh]

On Sun, Dec 14, 2008 at 08:29:57PM +0100, Ralf Mardorf wrote:
> Hi :)
> 
> 
> I removed the jack package by YaST2 and then ...
> suse11:/usr/lib # rm libjack*
> suse11:/usr/lib64 # rm libjack*
> 
> After I installed jack again, I got "jackd: error while loading shared
> libraries: libjackserver.so.0: cannot open shared object file: No such
> file or directory".

you need to run ldconfig as root.


-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [Jack-Devel] JACK for openSUSE 11.0 x86_64

[torbenh]

On Mon, Dec 15, 2008 at 06:26:49PM +0100, Ralf Mardorf wrote:
> oc2...@arcor.de wrote:
> > you can't do it this way ... 
> >
> > first note: rpm -i is totally wrong here., you don't want to install you 
> > want 
> > to do a upgrade or downgrade.
> >
> > second note: you need a package-manager to resolve this problem :)
> >
> > explantation:
> > jack and jack2 are providing the same "functionality", so you have to make 
> > a 
> > choice which package-family you want to use.
> > possibility a) install jack, libjack0 and libjackserver0 ==> 0.116.x
> > possibility b) install jack2, libjack2-0 and libjackserver2-0 ==> 1.9.x
> > Those two package-families are mutual exclusive.
> >
> > According the openSuSE shared library policy all shared libs are splitted 
> > out 
> > in seperate packages with the so-name in the package name.
> >
> > if you pull in the mentioned package from http://www.sonarnerd.net/suse11/
> > you need additional steps, as these package doesn't follow the original 
> > SuSE 
> > packages.
> 
> I first had a 0.109 install from the repo-oss. I upgraded by YaST2 to
> 0.116 from the Packman Repo and got the same as a lot of people got, see
> http://ardour.org/node/2271.
> 
> Some steps followed, see
> 
> * [LAD] JACK for openSUSE 11.0 x86_64
>    /Ralf
>   Mardorf/ /(Sun Dec 14 2008 - 21:29:57 EET)/
>   o Re: [LAD] JACK for openSUSE 11.0 x86_64
>  
> /torb...@email-addr-hidden/ /(Sun
> Dec 14 2008 - 21:37:10 EET)/
> + Re: [LAD] [Jack-Devel] JACK for openSUSE 11.0 x86_64
>    /Ralf
>   Mardorf/ /(Mon Dec 15 2008 - 02:23:07 EET)/
> 

just install a self built source OVER the stuff from the package.
and then run ldconfig as root.

there is no "i dont know how to use ldconfig"
it just does its thing. you dont need to give it options,
or interact with it. you just need to start it.

after it ran you can use the installed jackd.

i am really sorry, but you are making it very hard to help you.


> 
> Why, you always ignored what I was writing. You can read all messages
> here in the LAD mailing list archive.

random up and downgrading, and mixing several repos is very likely
to break your system.



-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] JACK for openSUSE 11.0 x86_64

[torbenh]

On Tue, Dec 16, 2008 at 02:15:59AM +0100, Ralf Mardorf wrote:
> oc2...@arcor.de wrote:
> > Am Montag, 15. Dezember 2008 schrieb Ralf Mardorf:
> >   
> >> Hi Oc2pus :)
> >>
> >> here is the information I got by rpm, I also checked jack only and
> >> dependencies by YaST2 and added the stuff that's unknown by the package
> >> management and including jack in it's name.
> >>
> >> oc2...@arcor.de wrote:
> >> 
> >>> please post the output of
> >>> rpm -qa | grep jack
> >>>   
> >
> >   
> >> spinymo...@suse11:~> rpm -qa | grep jack
> >> jackmeter-0.3-0.pm.1
> >> libjack2-0-1.9.0-0.pm.4   <
> >> jack_snapshot-0.0.3-0.pm.1
> >> jackbeat-0.6.3-0.pm.1
> >> jacktube-0.20-0.pm.1
> >> libjackserver2-0-1.9.0-0.pm.4 <=
> >> jackEQ-0.4.1-0.pm.2
> >> jackmixdesk-0.3-112.pm.svn20070530
> >> jack_capture-0.9.31-0.pm.1
> >> jack-scope-20080627-0.pm.1
> >> libjack-devel-0.116.1-0.pm.1   <==
> >> jackmix-0.4-0.pm.1
> >> qjacklam-0.3-0.pm.2
> >> jack-0.109.2-36.1 <===  NOT A PACKMAN PACKAGE
> >> jackmixdesk-gui-0.3-112.pm.svn20070530
> >> jackmaster-0.0.1-0.pm.1
> >> jack-rack-1.4.7-68.1
> >> libjack0-32bit-0.109.2-36.1 <= 
> >> jack2-1.9.0-0.pm.4   <=== 
> >> 
> >
> > I marked them with <
> >
> > your system is borked, yo have a total mixture of jack2 and jack
> > even 32bit variants in your system...
> >
> > this can't work,never ever :)
> >
> > you need 
> > jack2, libjackserver2-0 libjack2-0
> > OR
> > jack, libjackserver0, libjackserver0
> >
> > don't know how you managed to reach this installation mixture. 
> >
> > But if it helps you, you can continue  to write in all your known  
> > communities: 
> > 
> > its ALWAYS the packager's mistake!  and those packages are totally borked...
> > 
> >
> > A tip from me:  simply try gentoo, than YOU are the master of installing 
> > and 
> > compiling things. And if things won't work as expected, grab your own nose 
> > and yell around :)
> >
> >   
> >> Cheers,
> >> Ralf
> >> 
> 
> I just wrote about a bug, I never said that it's a sin to produce bugs,
> I produce bugs myself, but here I just installed and removed jack
> packages by YaST and at a later point by zypper. Because you guess that
> you are god, I won't report it to you. Sorry, my mental disorders
> differs to the once you have got. Please, don't care about my mails and
> postings. It's wasting time, we don't have enough in common to
> correspond about those things. I never installed jack2 by myself, it was
> installed as a dependency to jack. I can try to force, to remove jack2,
> libjackserver2-0, libjack2-0 and to install jack, libjackserver0, but
> the problem seems to be, that YaST and zypper aren't able to do this any
> more. I'm fine with Suse and Debian, but I'm not fine with people like
> you. I don't understand what's the problem with this. You don't need to
> write me your opinions, if you think that I'm faking bugs, let the
> people know that I'm a liar. I distinctly declared that I won't report
> bugs to some people. I like to help people that are using Suse and I
> like to get help. Maybe you should engage the services of Gentoo, if you
> don't like Suse users. It all started with 2 bugs I reported by details
> at Linux-Club, than I had to declare what my needs about a tool like
> Linux are. I stoped this conversation at Linux-Club and you are
> stalking. YOU DON'T NEED TO WRITE TO ME! I don't wish to have a
> discussion about different Linux-World-Views. And if you answer people,
> not only here, please read what they have written. Yes, as I've written,
> jack-0.109.2-36.1 is from repo-oss, maybe because I tried to downgrade
> to this package, perhaps I have written that. Will it be fine for you if
> I declare, that I'm totally wrong and you are god?
> 
> I JUST NEED HELP, BECAUSE I DON'T KNOW SOME THINGS, I DON'T NEED
> ACIDNESS! You are a stalker, don't follow me.

i dont understand you.
he pointed out the errors.
and told you how you should fix your system.

he is a bit annoyed, because your saying the packages are broken.
the packages are fine. YOU broke your system.
now fix it.

just remove the offending packages.
read the man page of rpm and remove them.
i guess you need the force option, because you got yourself into
dependency hell.

yast wont help you here.

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] JACK for openSUSE 11.0 x86_64

[torbenh]

On Tue, Dec 16, 2008 at 12:31:22PM +0100, oc2...@arcor.de wrote:
> Am Dienstag, 16. Dezember 2008 schrieb Thomas Kuther:
> 
> > @ oc2pus, jack in packman is broken, or YaST is. I set up a fresh
> > install in a virtual machine using 11.1RC1 and only added packman.
> >
> > Currently there is:
> > * pulseaudio-module-jack-0.9.12-8.5
> > * libjack0-0.116.1-0.pm.1
> >
> > Now if I tick the box in YaST to install "jack" it pulls in
> > libjackserver2-0 and jack, which of course breaks things, as it keeps
> > libjack0. zypper on the other side gets it right. See the screenshot!
> > http://gimpel.ath.cx/~tom/jack_weirdness.png
> 
> nor the packman package or yast is broken...
> 
> pulseaudio-module-jack has a (wrong ?) requires to jack instead libjack.so.1 
> (or a other program in your system) . And as there are more than one provider 
> for jack, yast pulls in the first provider for jack it finds.

and this is only possible because, there are 2 packages, for libjack and
jack. Why do you think we distibute them in one package ?
They make no sense without each other.

STOP SPLITTING JACK UP.

> So the bad packages in this dependency hell are the ones who has a "Requires: 
> jack"
> 
> > Regards,
> > Thomas
> have fun
> Toni
> 
> 
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] JACK for openSUSE 11.0 x86_64

[torbenh]

On Tue, Dec 16, 2008 at 02:05:05PM +0100, torb...@gmx.de wrote:
> 
> and this is only possible because, there are 2 packages, for libjack and
> jack. Why do you think we distibute them in one package ?
> They make no sense without each other.
> 
> STOP SPLITTING JACK UP.

Sorry, this might have sounded a little bit harsh.
But this is a message to ALL packagers.

not only packman, but also debian packagers.

It looks like we will stop supporting people with distros/repos
which split up the libraries from jackd. And just tell them
their distro is broken.


STOP SPLITTING JACK UP.

There is NO reason to do that.
So at least fix it with HARD Require of a matching jackd/libjack
version in both packages.

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] JACK for openSUSE 11.0 x86_64

[torbenh]

On Tue, Dec 16, 2008 at 12:31:22PM +0100, oc2...@arcor.de wrote:
> Am Dienstag, 16. Dezember 2008 schrieb Thomas Kuther:
> 
> > @ oc2pus, jack in packman is broken, or YaST is. I set up a fresh
> > install in a virtual machine using 11.1RC1 and only added packman.
> >
> > Currently there is:
> > * pulseaudio-module-jack-0.9.12-8.5
> > * libjack0-0.116.1-0.pm.1
> >
> > Now if I tick the box in YaST to install "jack" it pulls in
> > libjackserver2-0 and jack, which of course breaks things, as it keeps
> > libjack0. zypper on the other side gets it right. See the screenshot!
> > http://gimpel.ath.cx/~tom/jack_weirdness.png
> 
> nor the packman package or yast is broken...

hmm... ok. it looks like libjack0-0.109.2 is not requiring
jack-0.109.2.

and jack-0.109.2 only requires libjack0.so
which can be provided by libjack2 and libjack1.

i consider this broken.


-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] JACK for openSUSE 11.0 x86_64

[torbenh]

> > hmm... ok. it looks like libjack0-0.109.2 is not requiring
> > jack-0.109.2.
> >
> > and jack-0.109.2 only requires libjack0.so
> > which can be provided by libjack2 and libjack1.
> >
> > i consider this broken.
> 
> just for the records: 
> these are not packman packages.
> the packman packages contains a X.pm.Y in the release tag, the actual version 
> is 0.116.1.

well... i looked at some .pm packages.
only through rpmfind though.

ok. i am sorry that this whole thing contained so much negative energy,
but reading ralfs mail makes aggressive.

so lets drink some "virtual" beer together, and let this stuff
rest. And Ralf, i hope that, you see that apart from pointing out
the problem you did not help in solving this problem.

You only distracted us from solving the problem with 10kb mails.
and also pushed oc2pus into defense.

I dont care what happenend at linux club. And i dont think that its a
reason to get angry if you are being laughed at by some random forum
users. 

We are doing this because we like to do it. And such negative energy
just makes us care less.



they are probably not even 18. 



> 
> A lib-package normally doesn't contain a requirement to a program-package.
> 
> For my packages in the packman repository:
> As a reaction of this thread, I uploaded new packages for jack and jack2.
> They are now mutually exclusive and the user must change wich one to use. 
> Formerly jack2 was handled as a update to jack.I followed also the idea from 
> Torben to handle the jack-daemon like a library.
> 
> The "Requires" to the underlying library packages where already part of the 
> packman packages. So I hope the problems of upgrading/changing the 
> jack-versions are solved.

ok. i will have a look, when your package database has synched.
nedko also updated:
http://trac.jackaudio.org/wiki/SuggestedPackagingApproach

to make the fact more clear, that there MUST NOT be two versions,
of libjack.so on the system.

perhaps you can communicate this fact upstream to suse.
i dont know how these things works, and who builds the
"official" opesuse packages. or if they just copy a working package,
from the alternative repos.



trying to :)

> oc2pus

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] Audio Linux

[torbenh]

On Tue, Mar 03, 2009 at 09:16:01AM -0430, Agustin Ruiz Gamez wrote:
> Estoy muy agradado por su preocupacion por mi problema de audio, El
> problema mio es que sus implementaciones son en idioma ingles y yo
> vivo en Venezuela donde hablamos español y no puedo traducior
> completamente los terminos alli explicados. Les agradeceria si ustedes
> tienen alguna version en español, me lo hicieran llegar.

de que programas estas hablando ?
si hay algunos con lengua espanol (no castellano :(

por ejemplo la traduccion de ardour la completizaron
esta semana.

tienes que estar un poco mas specifico :)


-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] JACK and computer sleeping

[torbenh]

On Fri, Mar 06, 2009 at 01:01:01PM +0100, MarcO'Chapeau wrote:
> On Thu, 5 Mar 2009 09:07:10 -0500, Paul Davis 
> wrote:
> > On Thu, Mar 5, 2009 at 9:02 AM, nescivi  wrote:
> > 
> >> Hiho,
> >>
> >> It seems that JACK (just tested with v0.116) does not survive when the
> >> computer is put to sleep, and woken up again.
> >>
> >> Is there any reason why this is so?
> > 
> > 
> > JACK will see this as a major system malfunction. If you are using JACK,
> do
> > not let your computer sleep, or suspend, or engage in CPU frequency
> > scaling.
> > These all appear to JACK as indistinguishable from your audio interface
> > ceasing to function in a way that leads it to quit or die. Remember that
> > JACK is watching the passing of absolute time.
> 
> While cpu freq scaling *might* confuse JACK, it seems is not the case here.
> Sleep is a whole different story...

yup. i still using frequency scaling too, although it is going to fade
away, because, according to some kernel dev, you save more power with a
tickless kernel when cpu is running full speed

however my CPU is hotter then and the fan wouldnt stop, so i still
prefer frequency scaling ondemand governor.

i guess this is due to jack_get_microseconds using hpet timer default.
which shouldnt get hit by frequency changes.



-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments

[torbenh]

On Mon, May 18, 2009 at 12:10:45PM -0400, Paul Davis wrote:
> On Mon, May 18, 2009 at 11:57 AM, Rui Nuno Capela  wrote:
> >
> > from where i stand, qjackctl does not need jackdbus support whatsoever.
> > it's kind of the other way around, if i may say. and the way around is not
> > about qjackctl per se, but to plain old good command-line jackd.
> 
> i'd like to clarify (again) based on ongoing conversations in #jack.
> 
> the issue that qjackctl could consider is not jackdbus, or dbus in
> general. its the JACK control API that was discussed at LAC 2008.
> right now, qjackctl simply claims to know how to start the JACK
> server, offers a dialog to let the user pick settings, and then
> constructs a set of command line arguments for jackd.
> 
> this will continue to work forever, but it is less flexible than we
> would like (consider what happens every time JACK gets a new option
> added (or taken away). the control API allows a control application to
> query the jack server (actually, its really querying the library that
> contains the implementation of the jack server that the control app is
> linked with), and discover what the available parameters are etc. etc.
> 
> the dbus stuff is really mostly orthogonal to this (i stress the
> "mostly")  - its just another example of a control app/system. there's
> no reason why qjackctl would or should want to interact with it.
> 
> however, the one area where these things overlap is "auto-start". this
> is because what it means to "auto-start" a JACK server differs in the
> following two scenarios:
> 
> * vanilla JACK install - there is no "jack control" system in
> place or in use
> * with jackdbus - there is a daemon in place listening for
> requests to start/stop/reconfigure the server
> 
> in the first scenario, the ~/.jackdrc file (if it exists) takes care
> of auto-start. but if jackdbus is in use, then auto-start means
> something really quite different.

so please tell me why the dbus implementation CANT just read .jackdrc ?
i am really pissed on all you guys trampling on legacy stuff.

WHY cant jackdbus just use the .jackdrc if it does not find its own .xml
config ? or check, whether .jackdrc is newer than the xml ?

you always point at us saying we dont like dbus. its not about dbus. its
about dbus people ignoring legacy. stop breaking legacy !


-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments

[torbenh]

On Mon, May 18, 2009 at 07:15:23PM +0300, Nedko Arnaudov wrote:
> "Rui Nuno Capela"  writes:
> 
> >> So you complain about qjackctl missing support for jackdbus? Having that
> >> will be nice :)
> >>
> >
> > from where i stand, qjackctl does not need jackdbus support whatsoever.
> > it's kind of the other way around, if i may say. and the way around is not
> > about qjackctl per se, but to plain old good command-line jackd.
> 
> In jackdbus system qjackctl is unusable for starting and configuring the
> jack server (there is no jackd executable). However qjackctl can still
> be used to monitor xruns and DSP load and as a patchbay application.
> 
> > fwiw, qjackctl just runs the jackd server as documented and interfaces to
> > libjack through its plain client api. it has been doing this for years and
> > rightly so, imo.
> 
> Yup I know that. And this is why it works as patchbay and monitor app
> when used with jackdbus.
> 
> > however, by having jackdbus in the picture and when everybody would think
> > it would be the holy grail, it is breaking all that instead just because
> > it wants to rule the game on its own. it's doing it with complete
> > disregard to what long time qjackctl/jackd users have been thought. that's
> > disgraceful to say the least.
> 
> It is not breaking it is fixing issues. Or I'm wrong that qjackctl can't
> show messages generated by jackd when jackd is autolaunched by regular
> jack client application? Last time I checked those messages go to
> application's stdout (that is inherited from the parent process - the
> one of the normal jack client application).
> 
> The issue that started this holy war is that dbus enabled package that
> contains also jackd got into the hands of Fons and ate his babies. The
> problem is already fixed in svn. qjackctl will not work when dbus is
> enabled unless both jackdbus and jackd are compiled and installed and
> after the packager ignores the warning text at configure time. qjackctl
> will not work because there will be not jackd executable installed.

and why is this so complicated ? 
why not think a bit about legacy ?
this "i dont care for legacy" attitude is the problem. and it does not
help to say we think "dbus eats babies". this is just a cheap excuse.

we are pissed because you dont care.
and i am starting to care less and less for all this shit too.


> 
> > i strongly believe that all this trouble is a matter or something that
> > just has been overlooked on the jackdbus development, that is, a
> > misinterpretation, a bug that can be squashed right away once it's
> > perfectly identified.
> 
> Unless you point to what is wrong nobody who knows how jackdbus system
> operates will understand what you mean.
> 
> > however, if all that is due on a jackdbus design decision instead, then i
> > am sorry, i'll digress. a completely new qjackctl has to be written from
> > the ground up. just don't ask me to do it, at least anytime soon :)
> 
> I asked you to add support for jackdbus (there are qt dbus wrappers)
> more than a year ago. It was in December 2007 IIRC. Not that I hoped a
> lot even back then.
> 
> -- 
> Nedko Arnaudov 



> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] FST and JUCE-based plugins

[torbenh]

On Thu, May 28, 2009 at 07:11:55AM -0400, Paul Davis wrote:
> On Thu, May 28, 2009 at 6:20 AM, Julien Pommier  wrote:
> > Hi,
> >
> > I have noticed that all JUCE-based vst plugins do not work in fst (at
> > least their GUI and their internal message passing stuff). The reason
> > is that the JUCE framework is initialising its internal machinery (a
> > MessageManager etc) during the first call to the VST entrypoint, and
> > if the later call to effEditOpen is performed from a different thread,
> > then all sort of terrible things happens, and it ends with a deadlock.
> >
> > There is a discussion in the JUCE forum here:
> > http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?p=21530#21530
> >
> > Please note that I'm not asking for a fix, but I just want to let the
> > FST developers know about this problem !
> 
> Well, we'd like FST to work with as many different plugins as
> possible, so a fix would be nice.
> 
> I think Jules actually is making an unreasonable assumption when he
> mentions that JUCE is expecting the "initialize" and "open" calls to
> come in the same thread. "initialize" is purely about
> loading/initalizing the plugin DSP code - its entirely possible to run
> a VST plugin without ever opening its editor. The "open" is required
> only when the user asks to see the editor. Because of the way win32
> event loops work, the thread that is going to wait for events on this
> window also needs to be the one that creates it. There is no obvious
> reason why this would be the same thread that was used to initialize
> the plugin.
> 
> There are several other thread "wrappers" such as the Waves shell
> which face the same issues as JUCE but work just fine with FST. I'm
> entirely open to a fix in FST if there is one that doesn't look like a
> grotesque hack :)

i think i have fixed it in FST now. however, this will be much harder in
ardour. good luck :S

its pushed to branch main-thread in the fst git.

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [Jack-Devel] jack2's dbus name

[torbenh]

On Mon, Jun 15, 2009 at 04:37:09PM +0200, Lennart Poettering wrote:
> On Mon, 15.06.09 15:34, Stéphane Letz (l...@grame.fr) wrote:
> 
> > What I'm personally trying to achieve is a more "flexible" way (compared 
> > to what is currently a bit hard-coded in JAKC2 SVN) so that a DBus 
> > control component can be coded as a "plugin" to be possibly loaded in 
> > JACK server process. This new plugin model allows to keep basically 2 
> > ways of using JACK server :  the "old way" (typically starting the jackd 
> > server using Qjackctl control application) or the new way using DBus 
> > based control applications (after the DBus control plug-in has been 
> > properly loaded in JACK server).  (Keeping the "old-way" is also 
> > important on others platforms JACK2 runs on.)
> 
> Distributions will certainly enable the D-Bus code in JACK if they
> ship it. So, I have no problem with depending on a dbus'ified jack for
> this logic to work. After all crazy folks who disable the dbus support
> in jack because they think it's an abomination probably think that PA
> is an even worse abomination anyway, so there's not need to cater for
> them.
> 
> > If this new "control plugin" model is finally accepted by JACK  
> > community, then we'll distribute/package JACK2 compiled with the 1)  
> > option, so that it (at least) cooperates with PulseAudio. But 2) would  
> > then be optional, so PA can not rely on the DBus control plug-in to  
> > always be present.
> >
> > The 1) code uses  "org.freedesktop.ReserveDevice1.AudioXX" name, and 2) 
> > optional DBus plugin uses "org.jackaudio.service" name. If we want to 
> > implement your proposal, the we would need to request another name in  1) 
> > part, is that correct?
> 
> I think org.jackaudio.service should be fine. I don't think this
> automatic logic needs to work on non-D-Bus jack builds. As I see it
> you don't need to make any changes on jack for this to work. All I
> need is the guarantee that by the time the service name is registered
> on the bus jack is fully accessible. Otherwise we had a race here: if
> PA looks for the org.jackaudio.service name to appear on the bus and
> then imemdiately connects to it while jack isn't fully accessible yet
> PA would fail.

the existence of org.jackaudio.service object does not guarantee,
that jackd is connectable.

i guess we need a signal, which tells that a server has been started,
but i leave this to the dbus guys.

my primary concern is to have the pa jack backend fixed. 
lennart himself said its a TOY. and it really is.

i dont really understand why it works, but its pretty broken, for sure.


static int jack_process(jack_nframes_t nframes, void *arg) {
struct userdata *u = arg;
unsigned c;
jack_nframes_t frame_time;
pa_assert(u);

/* We just forward the request to our other RT thread */

for (c = 0; c < u->channels; c++)
pa_assert_se(u->buffer[c] = jack_port_get_buffer(u->port[c], nframes));

frame_time = jack_frame_time(u->client);

pa_assert_se(pa_asyncmsgq_send(u->jack_msgq, PA_MSGOBJECT(u->sink), 
SINK_MESSAGE_RENDER, &frame_time, nframes, NULL) == 0);
return 0;
}


it needs to be decoupled using a ringbuffer.
and maybe pulse should be running with a higher blocksize than jack ?



> 
> Lennart
> 
> -- 
> Lennart PoetteringRed Hat, Inc.
> lennart [at] poettering [dot] net
> http://0pointer.net/lennart/   GnuPG 0x1A015CC4
> ___
> Jack-Devel mailing list
> jack-de...@lists.jackaudio.org
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [Jack-Devel] jack2's dbus name

[torbenh]

On Fri, Jun 19, 2009 at 08:45:12AM +0200, Stéphane Letz wrote:
> 
> >
> > No. I don't "wait" and not for the end of the current period. All I do
> > is set a maximum limit to how much non-IO work I do in the RT loop per
> > iteration.
> >
> > Uh, I actually admit that the pseudocode I posted in
> > http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-June/ 
> > 023380.html
> >
> > is completely broken. Sorry for the confusion. The one I was  
> > describing down on
> >
> > http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-June/ 
> > 023370.html
> >
> > was correct.
> >
> > So, another try:
> >
> > 
> > for (;;) {
> > n = jack_client_wait()
> > process(n);
> > jack_cycle_signal();
> > while (jack_frames_since_cycle_start() < threshold) {
> > if (no_private_events_to_process())
> > break;
> > process_one_of_my_private_events();
> > }
> > }
> > 
> >
> > The early exit in the inner loop when there's nothing to do (which is
> > the usual case) is the key point here, I guess.
> >
> > Sorry for the confusion.

this discussion seems to go away from the real issue to implementation
details of pa.
however the deeper i read into stuff which is being called, the more
malloc and mutex_lock() i see. 

even with jack_cycle_signal we are having a thread, which is running at
the same priority as other jack threads, so it still has a certein
potential to choke the other jack clients. 


first of all lets assume jack is running with -p64 -n2 
(~3ms latency)

i am not sure if lennart is aware that jack often runs with such
latencies. i dont really care for event processing inside the RT loop.
however you cant know how many clients are following in the process
cycle, so you cant know a sane threshold value. 

what i am asking for is that events are either passed into your RT loop
via lock-free fifos, or you decouple your soft-RT stuff from jacks RT
stuff, which is not as soft as you think.

at least nobody is creating semaphores in jack_process code. 
if you insist on soft-RT behaviour, just decouple and do what you want.



> >
> > Lennart
> >
> > -- 
> > Lennart PoetteringRed Hat, Inc.
> > lennart [at] poettering [dot] net
> > http://0pointer.net/lennart/   GnuPG 0x1A015CC4
> > ___
> > Linux-audio-dev mailing list
> > Linux-audio-dev@lists.linuxaudio.org
> > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> 
> But why using a "timing" condition to know about "how much of this  
> event dispacthing" is going to be done?
> 
> Would it make sense to just process up to a specified number of  
> "waiting" events? So basically if events are waiting *now*, you  
> process some of them, and the one coming between now and the end of  
> the cycle would be processed next cycle.
> 
> , for (;;) {
>   n = jack_cycle_wait();
>  process(n);
>  jack_cycle_signal();
>  process_SOME_of_my_private_events(E);
>   }
> 
>   
> 
> Stephane
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [Jack-Devel] jack2's dbus name

[torbenh]

On Fri, Jun 19, 2009 at 04:12:32PM +0200, Lennart Poettering wrote:
> On Fri, 19.06.09 15:59, Stéphane Letz (l...@grame.fr) wrote:
> 
> >
> >>
> >>> first of all lets assume jack is running with -p64 -n2
> >>> (~3ms latency)
> >>>
> >>> i am not sure if lennart is aware that jack often runs with such
> >>> latencies. i dont really care for event processing inside the RT  
> >>> loop.
> >>> however you cant know how many clients are following in the process
> >>> cycle, so you cant know a sane threshold value.
> >>
> >> But that information could be made available, couldn't it? I mean, the
> >> Jack server has information about the graph, so it could make that
> >> information available to the clients.
> >
> > Hum...even if this info would be available, it does not say what  
> > *actual* duration would take the following clients ...
> 
> That doesn't matter. Everything that is needed is an upper boundary.
> 
> > Better keep the current separated simple solution, until it can be  
> > proven it is a real bottleneck.
> 
> I guess I can agree to that.

oh well... i guess i shut up. 
maybe you can find out yourself why pulseaudio wants to connect to
midi-ports.

maybe my intial mail was too offensive, whatever.
i apologise for reading your code.

> 
> Lennart
> 
> -- 
> Lennart PoetteringRed Hat, Inc.
> lennart [at] poettering [dot] net
> http://0pointer.net/lennart/   GnuPG 0x1A015CC4
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] JACK 0.117.0 released

[torbenh]

On Sat, Nov 14, 2009 at 05:58:30PM +, Victor Lazzarini wrote:
> I never looked at it, but is netjack built into jack now?

since 0.116.0... yes.
and jack2 has the netjack1 port merged in svn.

regarding the 0.116.x series:
however there was a bug with deadline management. resulting in
some "oddities" in some condition, which was fixed lately.

the alsa_io tools in 0.116.2 were a joke compared to the current
implementation. 




-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] JACK 0.117.0 released

[torbenh]

On Sun, Nov 15, 2009 at 02:36:28AM +0800, Ray Rashif wrote:
> 2009/11/15 Victor Lazzarini 
> 
> > I never looked at it, but is netjack built into jack now?
> 
> 
> I'd consider a build-time feature (i.e as long as you have libsamplerate it
> will compile with netjack driver) "built-in", so yes it was and is.

the output from the configure script is not correct. alsa_io wont be
built without libsamplerate, but net driver and netsource will.
wont have resampling support though. 
but celt makes this feature obsolete anyways. it will get removed soon.

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[LAD] adding session notifications to jack

[torbenh]

hi...

on a side note to the LADI discussion, which might even be my fault,
i want to tell you what i am currently up to.

in my opinion the inherent fail of session handler stuff, is that
somehow it wasnt easy enough or too complex to integrate lash support
into apps.

also many people didnt like to use some other ipc mechanism...

so to me the most natural way to do session notification was adding it
to jack. most apps are already listening for some jack callbacks.
(at least they should be listening for shutdown :)

so in my working copy of jack1 i have added 2 API calls:


typedef char *(*JackSessionCallback)(jack_session_event_t code, const char* 
session_dir, const char* prefix, void *arg);

int jack_set_session_callback(jack_client_t *client,
JackSessionCallback session_save_callback,
void *arg);

struct session_command * jack_session_notify (jack_client_t* client, 
jack_session_event_t code, const char *path );


by calling jack_session_notify() the session callbacks of the listening
clients are invoked.
they are supposed to save their state, and return a string which
specifies, how they want to be restarted. the prefix parameter is unique
and there is a method to make this persistent over session reload.

the aggregation of the returned strings and unique ids is returned by
the notify call.

i have also changed jack_client_open which is able to accept a client
specified unique id. (this must be used when reloading state, so that
clients can be found again 

so... a potential session handler is still required. and it needs to be
able to query the portconnections. 
in order to restore them. 

but clients are not required to have an extra dependency in order to
support sessions. 

you may have noticed that this is currently ignoring alsa connections.
but i think we only need to add a way to publish an alsa seq id
via this protocol. 

then a pure alsa client would also need to link to libjack and create a
jackclient with no ports and no process callback, in order to
participate in session handling.

i dont see a difference. it just links to "some" session handler lib.

the only disadvantage i am seeing currently is that apps are treating
jack like an abstract audio output, and getting a jack signal up to the
gui layers where the invokation of save is generally happening is a bit
cumbersome. 

so far i have only patched oom and ardour. and ardour doesnt quit yet,
when requested.

well... tell me what you think :)


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] adding session notifications to jack

[torbenh]

On Sun, Nov 22, 2009 at 05:21:07AM +1100, Patrick Shirkey wrote:
> 
> On 11/22/2009 04:49 AM, torbenh wrote:
> > hi...
> >
> > on a side note to the LADI discussion, which might even be my fault,
> > i want to tell you what i am currently up to.
> >
> > in my opinion the inherent fail of session handler stuff, is that
> > somehow it wasnt easy enough or too complex to integrate lash support
> > into apps.
> >
> 
> 
> Or not documented in a way that made it explicitly clear to a mortal 
> developer how to implement it quickly and correctly.

yeah. it was a bit annoying in lash, that you needed to poll on a
separate fd in order to get your notifications.

this approach takes advantage of the jack client thread, so you dont
need to look for it in your mainloop.

however: save is invoked from a different thread. so this is still not
totally easy.

> 
> 
> 
> > also many people didnt like to use some other ipc mechanism...
> >
> > so to me the most natural way to do session notification was adding it
> > to jack. most apps are already listening for some jack callbacks.
> > (at least they should be listening for shutdown :)
> >
> > so in my working copy of jack1 i have added 2 API calls:
> >
> >
> > typedef char *(*JackSessionCallback)(jack_session_event_t code, const char* 
> > session_dir, const char* prefix, void *arg);
> >
> > int jack_set_session_callback(jack_client_t *client,
> > JackSessionCallback session_save_callback,
> > void *arg);
> >
> > struct session_command * jack_session_notify (jack_client_t* client, 
> > jack_session_event_t code, const char *path );
> >
> >
> > by calling jack_session_notify() the session callbacks of the listening
> > clients are invoked.
> > they are supposed to save their state, and return a string which
> > specifies, how they want to be restarted. the prefix parameter is unique
> > and there is a method to make this persistent over session reload.
> >
> > the aggregation of the returned strings and unique ids is returned by
> > the notify call.
> >
> > i have also changed jack_client_open which is able to accept a client
> > specified unique id. (this must be used when reloading state, so that
> > clients can be found again
> >
> > so... a potential session handler is still required. and it needs to be
> > able to query the portconnections.
> > in order to restore them.
> >
> > but clients are not required to have an extra dependency in order to
> > support sessions.
> >
> > you may have noticed that this is currently ignoring alsa connections.
> > but i think we only need to add a way to publish an alsa seq id
> > via this protocol.
> >
> > then a pure alsa client would also need to link to libjack and create a
> > jackclient with no ports and no process callback, in order to
> > participate in session handling.
> >
> > i dont see a difference. it just links to "some" session handler lib.
> >
> > the only disadvantage i am seeing currently is that apps are treating
> > jack like an abstract audio output, and getting a jack signal up to the
> > gui layers where the invokation of save is generally happening is a bit
> > cumbersome.
> >
> > so far i have only patched oom and ardour. and ardour doesnt quit yet,
> > when requested.
> >
> > well... tell me what you think :)
> >
> >
> >
> 
> 
> 
> I like the simplicity of the approach.  FWIW, I would find it 
> straightforward to implement.
> 
> Would there be any issues with 20 different apps saving state at the 
> same time?

depends on how big the state is... 
but fwiw the notification callbacks are executed sequentially in the
current implementation.


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] adding session notifications to jack

[torbenh]

On Sat, Nov 21, 2009 at 09:33:06PM +, Harry Van Haaren wrote:
> Hey,
> 
> Also liking the simplicity, and I think it might be a nice feature to keep
> the possiblity to save:
> * the studio
> * the room
> * the project
> 
> Perhaps the user could "tagg" each app as what function it has/what its
> being used for,
> and then allow the saving of all apps with the same "tagg" to a file, for
> re-use?
> 
> EG:
> -name-   -tag-
> Qsynth   piano
> JackRack  piano   (well, its reverb really)
> calf piano   ( compressor)
> 
> and then save tagg piano, and you can reload the same programs?
> 
> It does substantially add to complexity I'm aware, but I like the concept of
> being able to save subsets of programs and reload them seperatly from the
> exact project that they were created in.
> It seems a really usefuly feature, get a brilliant piano sound, double click
> the file, and your done & playing!
> 
> Thats looking from a users point of view. I appreciate that including these
> features in JACK might not be the way to go, as its not  "core" jack
> functionality.
> 
> Thought I'd share this idea.. Cheers -Harry

the current implementation is not able to merge sessions. 
the uuid values used for identifying the apps to connect them up again,
are maintaned by the applications. and for this feature to work, the
sessionmanager would need to be able to change them while the session is
still stored.

we have some options but these clobber the simplicity a bit.
iE we could mandate that the uuid is a commandline argument. 

how we can solve this is up for discussion. 



-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] adding session notifications to jack

[torbenh]

On Sat, Nov 21, 2009 at 04:37:17PM -0500, David Robillard wrote:
> On Sat, 2009-11-21 at 18:49 +0100, torbenh wrote:
> > hi...
> > 
> > on a side note to the LADI discussion, which might even be my fault,
> > i want to tell you what i am currently up to.
> > 
> > in my opinion the inherent fail of session handler stuff, is that
> > somehow it wasnt easy enough or too complex to integrate lash support
> > into apps.
> > 
> > also many people didnt like to use some other ipc mechanism...
> > 
> > so to me the most natural way to do session notification was adding it
> > to jack. most apps are already listening for some jack callbacks.
> > (at least they should be listening for shutdown :)
> > 
> > so in my working copy of jack1 i have added 2 API calls:
> > 
> > 
> > typedef char *(*JackSessionCallback)(jack_session_event_t code, const char* 
> > session_dir, const char* prefix, void *arg);
> > 
> > int jack_set_session_callback(jack_client_t *client,
> > JackSessionCallback session_save_callback,
> > void *arg);
> > 
> > struct session_command * jack_session_notify (jack_client_t* client, 
> > jack_session_event_t code, const char *path );
> 
> What is jack_session_event_t?

enum { JackSessionSave, JackSessionQuit }

> > by calling jack_session_notify() the session callbacks of the listening
> > clients are invoked.
> > they are supposed to save their state, and return a string which
> > specifies, how they want to be restarted. the prefix parameter is unique
> > and there is a method to make this persistent over session reload.
> > 
> > the aggregation of the returned strings and unique ids is returned by
> > the notify call.
> 
> What is this unique ID?  Unique ID of what?

unique id, which is meant to persistent. a unique client id for the
session. 
jack_client_open is extended to accept this uuid. so upon session
restore, the client will have the same uuid again.
and the session manager will be able to query its jack client name.
and then be able connect things again.

> > so... a potential session handler is still required. and it needs to be
> > able to query the portconnections. 
> > in order to restore them. 
> 
> This could simply be implemented as another jack client, though, right?

yes. the session handler is simply another jack client.
(it might even be ardour :)

> 
> > but clients are not required to have an extra dependency in order to
> > support sessions. 
> > 
> > you may have noticed that this is currently ignoring alsa connections.
> > but i think we only need to add a way to publish an alsa seq id
> > via this protocol. 
> 
> Personally I think it's pretty reasonable to expect Jack session
> management to only support Jack things.  Jack is portable to systems
> where Alsa doesn't exist, for one thing.  We have MIDI and bridges
> between them, just keep the system clean, I say.  The session manager
> can deal with that crap if it wants to.

i have added:

void jack_client_set_cookie( jack_client_t *client, const char *key, const char 
*value );
char *jack_get_cookie_by_uuid( jack_client_t *client, const char *uuid, const 
char *key )

now. this allows for publishing such things.

> 
> > the only disadvantage i am seeing currently is that apps are treating
> > jack like an abstract audio output, and getting a jack signal up to the
> > gui layers where the invokation of save is generally happening is a bit
> > cumbersome. 
> 
> I like the simplicity of this, but this last part is a problem.  I'm not
> sure doing this in Jack1 where all callbacks are in the process thread
> is really appropriate.  Then again, I don't think all callbacks being in
> the process thread is appropriate, period ;)  I guess this is just
> another case of this error anyway, but an extremely bad one.  You're
> going to get a pretty severe drop-out saving a ton of stuff to disk in
> the audio thread!!

yup. i will fix this up. its not really complicated to do.
however it hasnt been a real problem yet. 


> 
> But this leads me to the main point I want to make:
> 
> My take on this general thing is that a simple API like this is very
> definitely the right path, but if anything I would like it not even tied
> to Jack itself either.  The reason session management has failed to take
> hold is too much implementation-defined crap, breaking APIs, complexity
> to implement, and all that kind of thing.
> 
> How about taking it one step farther:  define this API in a single C
> header, which would be very small, not tied to ANY implementation
> whatsoever, 

Re: [LAD] adding session notifications to jack

[torbenh]

On Sat, Nov 21, 2009 at 06:05:01PM -0500, David Robillard wrote:
> On Sat, 2009-11-21 at 23:36 +0100, torbenh wrote:
> > On Sat, Nov 21, 2009 at 04:37:17PM -0500, David Robillard wrote:
> [...]
> > > What is this unique ID?  Unique ID of what?
> > 
> > unique id, which is meant to persistent. a unique client id for the
> > session. 
> > jack_client_open is extended to accept this uuid. so upon session
> > restore, the client will have the same uuid again.
> > and the session manager will be able to query its jack client name.
> > and then be able connect things again.
> 
> Is there a purpose to this ID other than getting the client name?  If
> it's about client name, we should just use the client name.

what would happen if the name was already taken ?
i basically had lash in mind when i imlemented it. 

but the client name would not work, if i had a hydrogen running, and
loaded a session with another hydrogen. 


> 
> > i have added:
> > 
> > void jack_client_set_cookie( jack_client_t *client, const char *key, const 
> > char *value );
> > char *jack_get_cookie_by_uuid( jack_client_t *client, const char *uuid, 
> > const char *key )
> > 
> > now. this allows for publishing such things.
> 
> Excellent.  Jack has needed a metadata system really, really badly for
> ages.  Need to be able to set stuff for ports too though.  This could
> elegantly solve so many long standing problems of jack (e.g. the auto
> connect problem).
> 
> However, notes from a metadata nerd:
> 
> - The key should REALLY REALLY be a URI.  The manager (or whoever else,
> including JACK itself) needs to be able to actually infer some meaning
> from a "cookie", or the system isn't really that useful.  Because this
> is persistent, and can be used to convey meaningful information, using a
> free text (i.e. meaningless) key is an extremely bad idea.

its not really persistent. the client needs to set them.
and i dont have means yet, to set them from another client.
do you think thats necessary ?

> 
> - There should probably be an optional const char *type parameter, to
> specify the type of the value.
> 
> I still don't see why this uuid is needed when any existing client
> already has a unique name.

noted above, because the client name uniqueness doesnt necessary persist
between session loads.

> 
> > > But this leads me to the main point I want to make:
> > > 
> > > My take on this general thing is that a simple API like this is very
> > > definitely the right path, but if anything I would like it not even tied
> > > to Jack itself either.  The reason session management has failed to take
> > > hold is too much implementation-defined crap, breaking APIs, complexity
> > > to implement, and all that kind of thing.
> > > 
> > > How about taking it one step farther:  define this API in a single C
> > > header, which would be very small, not tied to ANY implementation
> > > whatsoever, and implementable by both plugins and hosts (this last part
> > > is a very big win IMHO).  All this header would define is a descriptor
> > > (struct) with the necessary methods.  Sort of a ladspa.h for session
> > > management, except even simpler.  How you actually get this descriptor
> > > would be the only implementation dependent part (e.g. a host could pass
> > > it to a plugin, or Jack could have a single new call to return it).
> > 
> > interesting idea. i am not sure about the semantics of the reply strings
> > in the plugin case though.
> 
> I don't understand what the reply string means.  You said "return a
> string which specifies, how they want to be restarted".  Specifies
> what/how, precisely?

oh... its the key to session reload.
it basically is the command line, thats needed to get this client up
again, and make it load its config.

(so simple clients might specify their config via commandline switches
or whatever) 

another special handling is for ardour, which isnt able to save a
session into some session dir.
so my current patch makes it save a snapshot, and puts the path to the
snapshot into a file in session dir.
then it returns: "alink_loader /path/to/session/.alink"


we have already identified a weakness for ncurses clients.
so we might need to specify some environment variables, which are usable
in these commandlines. $XTERM or something...


> 
> Cheers,
> 
> -dr

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] adding session notifications to jack

[torbenh]

On Sat, Nov 21, 2009 at 07:30:02PM -0500, David Robillard wrote:
> On Sat, 2009-11-21 at 19:03 -0500, David Robillard wrote:
> > Ah.  Maybe not very portable?

well... commandline parameters are not totally portable, thats true.
thats why i basically avoid to say that its commandline parameters.
on windows or osx, it might be something different.

also i dont have a restore callback. 
hmm... you proposed one int other mail i guess...


> > 
> > It seems sort of redundant to have restoring via command line when we
> > already have a restore callback that does that anyway.  What if instead
> > we give a unique ID to the application itself only(*).  Then, before
> > calling jack_client_open, the client must call
> > jack_client_set_id(myappid) so Jack (and/or the session manager) knows
> > what it is.  The session manager can then restore it via the usual
> > callbacks.  Then app authors only need to implement restore once, in the
> > callback, and don't have to deal with command line stuff at all (which
> > can be pretty annoying in some cases).  I suppose this requires that the
> > command line arguments of the app are basically irrelevant though, but
> > the appp could save those same settings to the save directory too...

err... which app doesnt support loading a statefile when being started
via commandline ?

i also think that the restore event only makes things more complex.

> > 
> > Just a thought, trying to make it simpler and purely API based.
> 
> On second thought, I see the utility of command line stuff, though maybe
> it should be sent as argc and argv for more portability and less
> nuisance for apps that just want to pass them straight through? (no need
> to assemble an actual command line string, which is both annoying and
> not portable)

on windows you only have an args string.
however i dont see what an app which cant save its state. (iE
jack_netsource, should do ?)

snprintfing some commandline string shouldnt be a problem at all. 
i dont see why this should be so complicated. 




> 
> Cheers,
> 
> -dr
> 

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] adding session notifications to jack

[torbenh]

On Sat, Nov 21, 2009 at 10:25:06PM -0500, David Robillard wrote:
> On Sun, 2009-11-22 at 01:46 +0100, torbenh wrote:
> > i also think that the restore event only makes things more complex.
> 
> It allows loading a different session without shutting down the app
> entirely, but I guess that's no big loss.  Apps shouldn't take forever
> to start up anyway :) (plus it's much more bug prone)

i am getting dizzy when i think of ardour receiving reload this other
session event :)

>  
> > > On second thought, I see the utility of command line stuff, though maybe
> > > it should be sent as argc and argv for more portability and less
> > > nuisance for apps that just want to pass them straight through? (no need
> > > to assemble an actual command line string, which is both annoying and
> > > not portable)
> > 
> > on windows you only have an args string.
> > however i dont see what an app which cant save its state. (iE
> > jack_netsource, should do ?)
> 
> Not sure what you're getting at here.  Of course apps have to save their
> state, that's the whole point?

netsource doesnt have code to save its state. 
its state is completely described by its commandline.
and i guess there are some small apps which are the same.
but argv wouldnt change matters here.

what i find cumbersome, is that youd need to mess with argv also.
(consider running app bla.conf ... edit stuff... session save. 
app would save .conf into session dir. so the 
correct startup is "app /path/to/.conf"

> 
> > snprintfing some commandline string shouldnt be a problem at all. 
> > i dont see why this should be so complicated. 
> 
> I don't think this makes it more complicated, but it does make it
> portable, standard C, and makes sense for libraries/plugins; but I don't
> really care enough to argue about it.  If jack_initialize and friends
> took an argv that would be a strong argument for it, but they just take
> an arbitrary string, so I guess that's an argument to use a string.  For
> internal clients the returned string would not be a command line but the
> argument to jack_initialize
(or a string containing jack_load :)


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] FOSS Ethernet Soundcard

[torbenh]

On Tue, Nov 24, 2009 at 08:34:53PM +0100, Karl Hammar wrote:
> Florian Faber:
> > Karl Hammar wrote:
> > > [..ethernet transports..]
> > > And we are missing an open protocol for this.
> > What is wrong with netjack? It's made for point-to-point and very
> > simple. You just have to solve the clock issue unless you want to lose
> > bit transparency.
> 
> Ohh, sorry, I got the impression it was not ready. I don't mind being
> wrong in that.

may i kindly ask what gave you that impression ?
i admit that some jack versions in svn were broken for the LAN use-case
because i am focussing on making it work for wireless and
transcontinental internet connections. 

but the lan use-case it pretty trivial and doesnt need all this deadline
machinery. 

if you just want to build a network soundcard, and use jack on a
computer with that, its ready for 3 years now !!!

having more than one network soundcard, and keeping stuff in sync is
more tricky. it requires that you can control the wordclock on that
soundcard, and you need a special version of alsa_out.c 
which instead of resampling controls the wordclock frequency.


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] FOSS Ethernet Soundcard

[torbenh]

On Thu, Nov 26, 2009 at 08:55:50AM +, Folderol wrote:
> On Thu, 26 Nov 2009 06:36:07 +0100
> torbenh  wrote:
> 
> > On Tue, Nov 24, 2009 at 08:34:53PM +0100, Karl Hammar wrote:
> > > Florian Faber:
> > > > Karl Hammar wrote:
> > > > > [..ethernet transports..]
> > > > > And we are missing an open protocol for this.
> > > > What is wrong with netjack? It's made for point-to-point and very
> > > > simple. You just have to solve the clock issue unless you want to lose
> > > > bit transparency.
> > > 
> > > Ohh, sorry, I got the impression it was not ready. I don't mind being
> > > wrong in that.
> > 
> > may i kindly ask what gave you that impression ?
> > i admit that some jack versions in svn were broken for the LAN use-case
> > because i am focussing on making it work for wireless and
> > transcontinental internet connections. 
> 
> I'm not sure why, but I had an impression of 'unreadiness' too :o

:S great.
did you try it, and it didnt work ?


> 
> > but the lan use-case it pretty trivial and doesnt need all this deadline
> > machinery. 
> > 
> > if you just want to build a network soundcard, and use jack on a
> > computer with that, its ready for 3 years now !!!
> 
> The remaining issue then is how much additional latency does netjack
> introduce? I think, eventually, this will turn out to be the most
> critical issue.

if you dont saturate the link, its one period.
you have the same problem with usb soundcards. 
for 100Mbit the threshold where you need 2 periods, is somewhere around 12 
channels. 


> 
> > having more than one network soundcard, and keeping stuff in sync is
> > more tricky. it requires that you can control the wordclock on that
> > soundcard, and you need a special version of alsa_out.c 
> > which instead of resampling controls the wordclock frequency.
> 
> If there is no internal sound card, why is there any need for alsa?
> 
> Wordlock may not be as difficult as it first seems. A bit I originally
> wrote to LAU...

if you have a master clock, and want to adjust your output to this, then
the alsa_out program would be what you want. 
it extracts the clock driving jackd, and is able to control a resampling
rate so that the phase is pretty constant.


> 
> > Looking up the AES spec quickly reveals 48kHz +/- 10ppm. If the
> > card's master oscillator has that kind of stability, it would surely
> > require only very tiny slow adjustments to keep two of them in sync.
> > Worst case would be them consistently drifting the maximum allowance in
> > opposite directions, which if my maths is up to scratch results in
> > about a second before they would actually get out of step by 1 cycle.
> > 
> > A quick google reveals 5ppm temp compensated oscillators with a a 7ppm
> > voltage controlled pull-in - no idea how much these cost though.
> 
> Even without this, I wonder what the audible effect on real music would
> be of just dropping one sample per second. It might be worth doing some
> experiments to find out.

i dont understand why you want that... 


> It also occurs to me that although we want to lock frequency, phase
> relationship between cards is a red herring. Signals from different
> sources will not have any phase relationship, so why should the cards?

alsa_out is able to deliver that. 
> 
> -- 
> Will J Godfrey
> http://www.musically.me.uk
> Say you have a poem and I have a tune.
> Exchange them and we can both have a poem, a tune, and a song.
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] FOSS Ethernet Soundcard

[torbenh]

On Tue, Dec 01, 2009 at 06:22:20PM +1100, Patrick Shirkey wrote:
> --
> Firmware/Software
> --
> 
> The device will run Linux OS.
> Audio data transfer will be via netjack using CELT compression.

heh ? you dont want lossy compression for a soundcard.
if you only intend to transmit 8 channels you dont need that.


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] Update of jconv

[torbenh]

On Tue, Dec 01, 2009 at 11:06:51PM +0100, f...@kokkinizita.net wrote:
> Hello all,
> 
> Updates of jconv, now called jconvolver, and the zita-convolver
> library are available on the usual place:
> /
> 
> The new zita-convolver is API-compatible to the previous
> release but not binary compatible. If you have any code
> using it please recompile.

when building zita-convolver-2.0.0 on x86_64 i got an error.
zita-convolver.cc:1: error: CPU you selected does not support x86-64
instruction set
i suggest using -march=native as default


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] FOSS Ethernet Soundcard

[torbenh]

On Wed, Dec 02, 2009 at 04:20:45PM +0100, Adrian Knoth wrote:
> On Wed, Dec 02, 2009 at 10:05:51AM -0500, drew Roberts wrote:
> 
> > > > Audio data transfer will be via netjack using CELT compression.
> > > Ack.
> > Can CELT also do uncompressed or lossless? 
> 
> That's called raw PCM. ;)
> 
> > Otherwise limiting to CELT might not be such a good idea if I have
> > followed things closely enough.
> 
> It's not a good idea. It imposes latencies and there's actually no need
> for compressed data as long as there is plenty of bandwidth (and there
> will be, since we're talking LAN)

the latency is just half a period. but there is no need for this. you
can transmit 100 uncompressed channels via GigE no problem.

well... having it built with celt support wont harm.
and that opens the possibility to connect to a soundcard in another
continent :)

well... note that the CPU should be able to handle the float conversions
in this case. if it doesnt have an FPU and you need to use soft-floats,
the conversions could use a significant share of CPU.


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] [LAU] Update of jconv

[torbenh]

On Wed, Dec 02, 2009 at 01:15:08PM +0100, f...@kokkinizita.net wrote:
> On Wed, Dec 02, 2009 at 12:32:12PM +0100, Arnold Krille wrote:
> 
> > On Wednesday 02 December 2009 11:09:18 f...@kokkinizita.net wrote:
> >
> > > non-RT, while these extra threads remain at RT. So
> > > they will pre-empts Jack's thread and will appear to
> > > be always ready on time. Except when you have 2 CPUs:
> > > then Jack's thread will be allowed to continue even
> > > if some of the others have not yet completed their
> > > work.
> > 
> > Wouldn't the easiest solution be to wait for the worker-threads when in 
> > freewheeling mode?
> 
> It's not the only solution but surely the easiest.
> The semaphores that would be required are already
> in place (they are used for checking readyness now).

hmm... but thats the trigger semaphore.
and the worker thread blocks on it. so the process thread cant block on
it. or are you talking about some non released code ?

> 
> The complicated part could be switching between the
> two regimes. I suspect this can't be done 'instantly',
> it could require a multi-step process spread over a
> series of periods. 
> 
> Maybe I'm overestimating the complexity, but I try
> to step gently as organising the cooperation of these
> threads was not a simple task. The code looks simple,
> but that's the result of my usual irresistable urge
> to simplify every algorithm down to its essentials.
> 
> I've not really tried to solve this ATM, but will do
> if some free time drops from the (currently) blue
> Italian sky.

i added a semaphore like construct built with pthread_cond
the RT thread only decrements the counter and in sync mode
wait for the counter to be zero.

this allows instant switching. 

using more than 1 line for syncying clutters the code though, but as
this kind of stuff is a matter of taste, i leave that up to you to
move it into a separate method or class.

patch is attached

-- 
torben Hohn
diff --git a/jconvolver-0.8.4/source/jclient.cc b/jconvolver-0.8.4/source/jclient.cc
index 5feb421..c57bd71 100644
--- a/jconvolver-0.8.4/source/jclient.cc
+++ b/jconvolver-0.8.4/source/jclient.cc
@@ -30,7 +30,8 @@ Jclient::Jclient (const char *name, Convproc *conv) :
 _mode (PM_CONVOL),
 _ninp (0),
 _nout (0),
-_conv (conv)
+_conv (conv),
+_fweel (0)
 {
 init_jack ();  
 }
@@ -138,10 +139,16 @@ void Jclient::jack_static_shutdown (void *arg)
 
 void Jclient::jack_static_freewheel (int state, void *arg)
 {
+Jclient *me = (Jclient *) arg;
 if (state)
 {
-	fprintf (stderr, "WARNING: jconvolver may not work correctly in freewheel mode.\n");
+	if( me->_conv )
+	me->_conv->drop_rt ();
+} else {
+	if( me->_conv )
+	me->_conv->get_rt ();
 }
+me->_fweel = state ? true : false;
 }
 
 
@@ -224,7 +231,7 @@ void Jclient::jack_process (void)
 	}
 }
 
-_conv->process ();
+_conv->process ( false, _fweel );
 
 for (i = 0; i < _nout; i++)
 {
diff --git a/jconvolver-0.8.4/source/jclient.h b/jconvolver-0.8.4/source/jclient.h
index 80240d0..998e188 100644
--- a/jconvolver-0.8.4/source/jclient.h
+++ b/jconvolver-0.8.4/source/jclient.h
@@ -69,6 +69,8 @@ private:
 unsigned int_ninp;
 unsigned int_nout;
 Convproc   *_conv;
+bool	_fweel;
+
 
 static void jack_static_shutdown (void *arg);
 static void jack_static_freewheel (int state, void *arg);
diff --git a/zita-convolver-2.0.0/libs/zita-convolver.cc b/zita-convolver-2.0.0/libs/zita-convolver.cc
index 9cb45ad..96fe319 100644
--- a/zita-convolver-2.0.0/libs/zita-convolver.cc
+++ b/zita-convolver-2.0.0/libs/zita-convolver.cc
@@ -282,7 +282,7 @@ int Convproc::cleanup (void)
 }
 
 
-void Convproc::process (bool skip)
+void Convproc::process (bool skip, bool sync)
 {
 unsigned int f, k;
 
@@ -296,7 +296,7 @@ void Convproc::process (bool skip)
 {
 _outoffs = f = 0;
 	for (k = 0; k < _nout; k++) memset (_outbuff [k], 0, _minpart * sizeof (float));
-	for (k = 0; k < _nproc; k++) f |= _procs [k].readout (skip);
+	for (k = 0; k < _nproc; k++) f |= _procs [k].readout (skip, sync);
 if (f)
 	{
 	_flags |= f;
@@ -327,7 +327,21 @@ void Convproc::print (void)
 for (k = 0; k < _nproc; k++) _procs [k].print ();
 }
 
+int  Convproc::get_rt ()
+{
+unsigned int k;
+int f=0;
+for (k = 0; k < _nproc; k++) f |= _procs [k].get_rt ();
+return f;
+}
 
+int  Convproc::drop_rt ()
+{
+unsigned int k;
+int f=0;
+for (k = 0; k < _nproc; k++) f |= _procs [k].drop_rt ();
+return f;
+}
 
 typedef float FV4 __attribute__ ((vector_size(16)));
 
@@ -338,6 +352,7 @@ Convlevel::Convlevel (void) :
 _parsize (0),
 _vectopt (0),
 _pthr (0),
+_done_count (0),
 _inp_list (0),
 _out_list (0),
 _plan_r2c (0),
@@ -346,6 +361,8 @@ Convlevel::Convlevel (void) :
 _prep_data (0),
 _freq_data (0)
 {
+pthread_mutex_init (&_sync_lock, NULL);
+pthread_cond_init (&_done, NULL);
 }
 
 
@@ -551,10 +568,10 @@ v

Re: [LAD] Development Release - JACK-sync'd Arpeggiator - arpage

[torbenh]

On Sat, Dec 12, 2009 at 06:45:42PM +0100, Adrian Knoth wrote:
> On Sat, Dec 12, 2009 at 12:15:19PM -0500, Mark Vitek wrote:
> 
> > Hello all,
> 
> Hi!
> 
> > I'm currently writing an arpeggiator that syncs to JACK tempo. It's
> > starting to get usable, and I'm running out of excuses not to let
> > others try it out.
> 
> > Looking forward to any and all feedback.
> 
> It would have been good to provide a link to , so
> people don't have to guess where it is. ;)
> 
> 
> I have a rather big feature proposal: LV2 support. That is, make a
> one-channel-instsance of this "plugin" which can be loaded in
> LV2-capable hosts. I don't know if LV2 already provides everything you
> need (e.g. query the host beat position), but with ardour-3.0, an LV2
> arpeggiator would really be useful.

we dont have a tempo/transport extension in LV2 yet.
this needs to be solved before this could be implemented.


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] LADI

[torbenh]

On Sun, Dec 20, 2009 at 11:23:54AM +0100, rosea grammostola wrote:
> Gabriel M. Beddingfield wrote:
> > When I'm not in group 1, I'm hanging out in group 4. 
> > Inter-host and headless session management is important to 
> > me, too.
> >
> > I really do hope that Fons releases his code. :-)
> 
> @Fons, thanks for your reply. It seems that you're not planned to make a 
> session handler for the mass... That's not bad at all in many cases. 
> Good luck with it and I hope you decide to release your code.
> 
> Ok, roughly we have 4 groups now (assuming that we can call >1 
> individuals a group ;) )
> 
> Group 1 has spoken, group 3 and group 4.
> 
> What can we expect from group 2? Maybe some of the lash developers 
> belongs in this group?
> Dave, Juuso, Bob Ham, ... ? What are your plans now?

dunno... jack session is frozen now. 
it took a huge flame war to find out some implications of the
requirements.

so basically i dont think we can reach consensus.
and sessionhandling is _only_ about consensus. its not a problem at all
to implement.

lad is dead.

> 
> 
> Regards,
> 
> \r
> 
> 
> 
> 
> 
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] LADI

[torbenh]

On Sun, Dec 20, 2009 at 09:11:04PM +0100, rosea grammostola wrote:
> torbenh wrote:
> > On Sun, Dec 20, 2009 at 11:23:54AM +0100, rosea grammostola wrote:
> >> What can we expect from group 2? Maybe some of the lash developers 
> >> belongs in this group?
> >> Dave, Juuso, Bob Ham, ... ? What are your plans now?
> >> 
> >
> > dunno... jack session is frozen now. 
> >   
> Torben, thanks for your reply.
> 
> Can you, for the people who didn't follow the development of jack 
> session, shortly point out what jack session does.
> 
> 1) What do you want to achieve with jack session.

session management ? 
load/save of whole jack graph .

> 2) How do you think you are able to achieve it?

with very few exceptions every app thats a target for session
management, is a jack client. 
so why not add some callbacks, and let the sessionmanager 
communicate with apps via jack ?

this basically reduces the size of the app patches. 
allowing me to patch at least one app per hour. 

> 3) Why do you think this is the best way to do it?

every app is already using jack IPC to communicate with jackd.
-> minimally invasive on the app.
no reinvention of the wheel or yet another IPC mechanism to add.

anyways... effort is frozen. 
we are dumping a working implementation.


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] LADI

[torbenh]

On Mon, Dec 21, 2009 at 06:35:47PM -0600, Gabriel M. Beddingfield wrote:
> 
> 
> On Tue, 22 Dec 2009, Patrick Shirkey wrote:
> 
> >So you agree with Fon's statement that if the jack_session code is
> >accepted you would not want to use jack1 any longer and would support a
> >fork or stop using it completely and create your own realtime audio daemon?
> 
> Probably about as much as you agree with Stéphane's threat to do the
> same over dbus (which, IIRC, is closely related to the session
> management debates). :-)
> 
> >I must have missed the part of the debate where it was agreed or even
> >defined that jack_session would not be able to play nicely with more
> 
> Here's a few with the most recent proposal:
> 
> * save/restore requires application to shut down and
>   restart.
> 
> * session callback does not work asynchronously

so you want it async ?
well... lets make it async then ? 


> 
> * process call graph must be halted during the
>   session callback (a consequence of not being
>   asynchronous).

wrong.

> 
> Also, I wasn't comfortable with how the serialization should work...
> but it was too early in the process to pick nits on that.

please state your problems.

> 
> >As far as I can tell the design process broke down mostly because one
> >person made a strong case for not having any other form of session
> >management except the one that he is working on (and is now saying he is
> >not interested in releasing publicly) and consequently wound the other
> >parties up to the point where they decided it was too frustrating or
> >stressful to discuss it any further at that point.
> 
> Once it's in the JACK API, it won't be coming out. Likewise,
> changing it will be very difficult after the fact... so it needs to
> be right.
> 
> If it's not in the JACK API, there is no argument.
> 
> -gabriel

> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[LAD] gcc and pointer aliasing... missing optimizations in some cases

[torbenh]

hi...

i discovered yesterday, that gcc cant optimize something like:

---
class Ramp
{
private:
float _phase;
float _omega;
public:
Ramp();
float process()
{
_phase += _omega;
return  _phase;
}
};

Ramp osc_block;


int process( jack_nframes_t nframes, void *arg )
{
int i;

float * __restrict__ buf = (float *) jack_port_get_buffer( out_port, 
nframes );

for( i=0; ihttp://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] gcc and pointer aliasing... missing optimizations in some cases

[torbenh]

On Tue, Dec 22, 2009 at 05:55:08PM +0100, torbenh wrote:
> 
> hi...
> 
> i discovered yesterday, that gcc cant optimize something like:
> 
> ---
> class Ramp
> {
> private:
>   float _phase;
>   float _omega;
> public:
>   Ramp();
>   float process()
>   {
>   _phase += _omega;
>   return  _phase;
>   }
> };
> 
> Ramp osc_block;
> 
> 
> int process( jack_nframes_t nframes, void *arg )
> {
> int i;
> 
> float * __restrict__ buf = (float *) jack_port_get_buffer( out_port, 
> nframes );
> 
> for( i=0; i   buf[i] = osc_block.process(); 
> }
> }
> ---
> 
> the __restrict__ on buf is not enough to convince gcc that writing to
> buf[i] doesnt clobber _phase or _omega;
> 
> i am trying to make a case here, that something stronger than
> __restrict__ is needed which allows the programmer to state that a
> pointer really doesnt alias to anything.
> 
> of course the gcc guys say "wont happen" ... 
> so the question is whether we have enough need for this in the dsp
> scene... and maybe some political power ?
> 
> am i totally wrong and such idioms arent of much use ?

maybe i should have posted the resulting code:

.L5:
movss   osc_block+4(%rip), %xmm0
addss   osc_block+8(%rip), %xmm0
movss   %xmm0, osc_block+4(%rip)
movss   %xmm0, (%rax,%rdx,4)
addq$1, %rdx
cmpl%edx, %ebx
ja  .L5
.L7:
popq%rbx
ret
> 
> 
> 
> -- 
> torben Hohn
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] gcc and pointer aliasing... missing optimizations in some cases

[torbenh]

On Tue, Dec 22, 2009 at 02:11:23PM -0600, Gabriel M. Beddingfield wrote:
> 
> 
> On Tue, 22 Dec 2009, Gabriel M. Beddingfield wrote:
> 
> >Thus telling the compiler that `this` is not an alias when
> >process() is called.
> 
> On second thought... since those didn't work for me, perhaps part of
> the problem is that osc_block is a global variable, and thus there's
> no way to prove __restrict__ on it.
> 
> -gabriel

fields of structs are not unaliased, even when the pointer to the struct
is __restrict__



-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] gcc and pointer aliasing... missing optimizations in some cases

[torbenh]

On Sat, Dec 26, 2009 at 10:50:40AM +0100, Tim Blechmann wrote:
> >>> Thus telling the compiler that `this` is not an alias when
> >>> process() is called.
> >>
> >> On second thought... since those didn't work for me, perhaps part of
> >> the problem is that osc_block is a global variable, and thus there's
> >> no way to prove __restrict__ on it.
> >>
> >> -gabriel
> >
> > fields of structs are not unaliased, even when the pointer to the struct
> > is __restrict__
> 
> did you check http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187?

sure. its marked as fixed, and it seems to be fixed.
the thing i am talking about is not a bug.

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] aseqmm 0.2.0 released

[torbenh]

On Sun, Dec 27, 2009 at 04:25:11PM +0100, Pedro Lopez-Cabanillas wrote:
> aseqmm is a C++ wrapper around the ALSA library sequencer interface using Qt4 
> objects, idioms and style. ALSA sequencer provides software support for MIDI 
> technology on Linux. Several examples are included in the source tree.

hmm... maybe its just me. but to me the name aseqmm would imply it uses
sigc and gobjects.

wouldnt qaseq be amore appropriate name ?


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] GUI for audio application

[torbenh]

On Tue, Dec 29, 2009 at 05:05:01PM +0800, Ray Rashif wrote:
> Aside from that, we have to forget about everything that has anything
> to do with GTK+. None of what you look forward to is even remotely
> possible with the examples and advice given so far (I mean just one
> look at libphat is..urghhh just another gtk design).
> 
> Flashy and elegant is Qt's forte, because LMMS has done it. Your
> resulting app can be simple, good-looking, skinnable. There's EFL, but
> no-one knows whether it's even usable for multimedia.

what is this ? gui flamewars ?
idiots.


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] GUI for audio application

[torbenh]

On Tue, Dec 29, 2009 at 02:56:25PM +0100, Pedro Lopez-Cabanillas wrote:
> On Tuesday, December 29, 2009, torbenh wrote:
> > what is this ? gui flamewars ?
> > idiots.
> 
> So, I must ask for permission to the high priests before naming my library, 
> but you can freely insult to everybody not sharing your faith ?
> 
> BTW, many applications made with GTK are ugly for my taste, and I have also 
> technical complains against it.

consider yourself insulted now.


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] ttsoot - yet another DSP library :)

[torbenh]

hi... 

i am working on a c++0x DSP library. 
variadic templates prove to be a nice way to handle
the massive function inlining required to build efficient samplebased
processing graphs.

the idioms i am currently using for the containers require gcc-4.5
though, so this is still a bit of a show-stopper :)

its still in a pretty early state. but you can already see where its
heading. 

if somebody is interested:
http://hochstrom.endofinternet.org/trac/ttsoot/wiki

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] Has anyone managed to compile this?

[torbenh]

On Sat, Jan 16, 2010 at 12:08:48AM +, Victor Lazzarini wrote:
> Dear all,
> 
> Torben's  new project  brought  back to my mind this mind-bending
> C++ template example (see attached), which I could not yet get to
> compile, I have been told it has been compiled, but g++ will have
> none of it. So I still have doubts on whether it includes legal C++
> code or not. But it is an interesting example (even if it does not
> build) of what (possibly) can be done with templates.
> 
> My question to the list is: has anyone managed to compile this code?

its missing several occasions of typename
(basically every error just requires adding typename, and it can be
compiled.)

see attachment.
> 
>
> Regards
> 
> Victor


> 

> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev


-- 
torben Hohn
//
// A C++ program to test for the primality of the number 13
//
// It has the curious property that it does no arithmetic
// but uses only the template mechanism and class derivation
// to achieve its result. It starts at the most basic axioms
// of arithmetic starting with the definition of zero and
// its successors...
//
// You'll need a good C++ compiler.
//
// (c) D Piponi (But copy it as much as you like if you credit me)
//

//
// First a little trick to find the base class of our
// classes because the template mechanism requires
// exact matches.
//
// Two values are considered equivalent if they have
// the same baseclass. For example 1+1 isn't
// identical to 2 but 1+1 *is* derived from 2.
//
template struct Value { typedef V value; };

//
// Define zero
//
struct zero
   : public Value { };

//
// Define the successor of an integer
//
template struct S
   : public Value > { typedef C predecessor; };

//
// Now we have the integers. So introduce some convenience
// types.
//
typedef S one;
typedef S two;
typedef S three;
typedef S four;
typedef S five;
typedef S six;
typedef S seven;
typedef S eight;
typedef S nine;
typedef S ten;

//
// Define plus,...
//
template struct plus
  : public S > { };

template struct plus
   : public C { };

//
// ...minus...
//
template struct minus
   : public minus::predecessor { };

template struct minus
   : public C { };

//
// ...and times.
//
template struct times
   : public plus::value> { };

template struct times
   : public zero { };

//
// Define the usual ordering on the integers.
//
template struct ge
   : public ge { };

template struct ge
   : public one { };

template struct ge
   : public zero { };

template<> struct ge
   : public one { };

//
// Divisibility testing
//
template > > struct Divisible { };

template struct Divisible > >
   : public Divisible::value> { };

//
// The case C struct Divisible
   : public zero { };

template struct Divisible
   : public one { };

//
// The case C>=D:
// D divides C iff D divides C-D.
//
template struct Divisible >
   : public Divisible::value,D> { };

//
// Primality testing
//
template struct Prime { };

//
// We use recursion to set up a loop from 2 to one less
// than the integer we are testing. Essentially this is a state machine
// using template parameters to record the current state.
//

// Are we at the end of the recursion?
//
template struct Prime
   : public Prime::value> { };

//
// Test potential factor D, trying successor on failure.
//
template struct Prime
   : public Prime,zero,typename Divisible::value,zero> { };

//
// Found a factor.
//
template struct Prime
   : public zero { };

//
// Reached the end of the loop without finding divisor.
//
template struct Prime
   : public one { };

//
// Convenience method for humans allowing input of
// numbers in decimal format.
//
template struct Decimal
   : public plus::value,D> { };

//
// Unfortunately the I/O interface spoils the purity of it all.
//
#include 

template char *output(C);

template<> char *output(zero) { return "No"; }

template<> char *output(one) { return "Yes"; }


main() {
   //
   // Is 13 prime?
   //
   puts(output(Prime::value>::value()));
}
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] Has anyone managed to compile this?

[torbenh]

On Sat, Jan 16, 2010 at 12:08:48AM +, Victor Lazzarini wrote:
> Dear all,
> 
> Torben's  new project  brought  back to my mind this mind-bending
> C++ template example (see attached), which I could not yet get to
> compile, I have been told it has been compiled, but g++ will have
> none of it. So I still have doubts on whether it includes legal C++
> code or not. But it is an interesting example (even if it does not
> build) of what (possibly) can be done with templates.
> 
> My question to the list is: has anyone managed to compile this code?
> 
> Regards
> 
> Victor

oh... and while we're at it... adi pointed me to some really sick stuff:
http://ompf.org/forum/viewtopic.php?f=8&p=17034



> 

> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] ttsoot - yet another DSP library :)

[torbenh]

On Fri, Jan 15, 2010 at 10:49:21AM +0100, Stéphane Letz wrote:
> 
> Le 15 janv. 2010 à 10:03, torbenh a écrit :
> 
> > 
> > hi... 
> > 
> > i am working on a c++0x DSP library. 
> > variadic templates prove to be a nice way to handle
> > the massive function inlining required to build efficient samplebased
> > processing graphs.
> > 
> > the idioms i am currently using for the containers require gcc-4.5
> > though, so this is still a bit of a show-stopper :)
> > 
> > its still in a pretty early state. but you can already see where its
> > heading. 
> > 
> > if somebody is interested:
> > http://hochstrom.endofinternet.org/trac/ttsoot/wiki
> > 
> > -- 
> > torben Hohn
> 
> 
> How would this approach compare to the FAUST approach?

its more or less equivalent to faust scalar code.
the containers provide similar composition ops to the faust ones.

but since my primitives are classes i can provide richer primitives
than faust.

i dont really see a way to automate what vector mode is doing.
but it should be possible to define a set of blockbased containers.

so that:

Chain< Blocked< A,B,C >, Blocked< D,E,F > >::process_block()

would expand to 2 loops.


> 
> Stephane 

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Time & How to approach it

[torbenh]

On Wed, Jan 20, 2010 at 09:01:36PM +0100, Olivier Guilyardi wrote:
> On 01/20/2010 08:24 PM, Harry Van Haaren wrote:
> 
> > Thanks for the JackMidi crash course. That's definatly some food for
> > thought.
> > I've tried to get the JACK Midi things working before, but I've never
> > managed.
> > I see the value in the sample-accurate-ness of JACK midi, so I think ill
> > skip the
> > AlsaSeq implementation. I've the docs there though, seem noteworthy just to
> > have read.
> 
> No problem, I'm glad to help.
> 
> However, please note that there's a bit of utopia in my explanations, because
> AFAIK there are quite a few apps out there which neither support JACK Midi 
> (only
> ALSA), nor deal or even care about the BBT and BPM info from the jack 
> transport
> position.
> 
> So you may need to be more specific about which other software you want your 
> app
> to interact with, to make a definitive decision about ALSA Midi support, 
> etc...
> 
> That said, JACK Midi is indeed truly smart IMO.

well.. the real problems are a bit deeper.
and not really touched be any example clients. 

you need to have lockfree access to the note sequence.
while still being able to manipulate it from the gui thread.

several approaches to achieve this are possible. and it depends a bit on
taste and the app to select them.

but the major part of complexity lies here.

> 
> --
>   Olivier
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Time & How to approach it

[torbenh]

On Thu, Jan 21, 2010 at 07:48:20AM -0500, Paul Coccoli wrote:
> On Thu, Jan 21, 2010 at 6:37 AM, torbenh  wrote:
> > well.. the real problems are a bit deeper.
> > and not really touched be any example clients.
> >
> > you need to have lockfree access to the note sequence.
> > while still being able to manipulate it from the gui thread.
> >
> > several approaches to achieve this are possible. and it depends a bit on
> > taste and the app to select them.
> >
> > but the major part of complexity lies here.
> >
> 
> I assume std::priority_queue can't be used, because it uses a
> std::vector which will, under the covers, allocate memory from the
> stack.

you can specify an Allocator for most STL containers.
but i am not aware of anybody using them with an RT safe allocator.
might be possible.

but the allocator is not the problem.
its lockfree access. 

> 
> It would be interesting to try to write an STL queue-like container
> with an allocator that grabbed chunks of memory from a pool in an
> RT-safe way.  Maybe via message-passing over a ringbuffer?  Anyone
> seen/have such a thing?

dunno... i never looked at implementing an allocator. 
shouldnt be that hard.

but as stated, this is still a trivial part of the problem.


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] tschack ... early version of smp enabled jack1

[torbenh]

hi...

since i dont want to let jack1 codebase die in a feature freeze,
i added some features.

- smp aware
- clickless connections

these changes are too radical to be included in mainline jack1.
so it gets a new name.
its approaching beta status now. dunno... maybe someone is motivated to
test it. 

http://hochstrom.endofinternet.org/trac/tschack/wiki



-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[torbenh]

On Mon, Jan 25, 2010 at 11:01:53PM +0100, hollunder wrote:
> Excerpts from torbenh's message of Sun Jan 24 22:05:49 +0100 2010:
> > 
> > hi...
> > 
> > since i dont want to let jack1 codebase die in a feature freeze,
> > i added some features.
> > 
> > - smp aware
> > - clickless connections
> > 
> > these changes are too radical to be included in mainline jack1.
> > so it gets a new name.
> > its approaching beta status now. dunno... maybe someone is motivated to
> > test it. 
> > 
> > http://hochstrom.endofinternet.org/trac/tschack/wiki
> 
> Thanks Torben, clickless connections sound interesting, smp is pointless
> on my current system. Nevertheless I'll package it for the Arch Linux
> User Repository, as mentioned on IRC today. I won't have a lot of time
> to test it in the near future, but it should make it a little bit easier
> for others.
> 
> I have a few questions tough:
> 1) Is it a full replacement for jack1? I assume it is, but you never

yup. its basically jack1 with a pretty big patch.

> know..
> 2) Is there a chance that it will be merged back to jack1 someday?

no chance at all. jack1 is in almost feature frozen. 
the only update it will see is the new latency API

this is also such a big change, that most experience with the old
codebase is not valid for this one.

jack1 is supposed to be rock-solid, based on several years of experience
with this mechanism. ripping the guts out, and turning it upside down,
and afterwards "selling" it to users as the "rock solid jack1" isnt
fair. 

this is a new implementation, and it needs to gain trust by itself.

that said, it survives bad treatment by the oom guys without xruns.
i basically consider it more robust than jack1, but since we only have
2-3 days experience with it, we cant be sure that its bug-free.

> 
> Thanks,
> Best regards,
> Philipp
> 
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[torbenh]

On Tue, Jan 26, 2010 at 12:38:53PM +, Chris Cannam wrote:
> On Sun, Jan 24, 2010 at 9:05 PM, torbenh  wrote:
> > since i dont want to let jack1 codebase die in a feature freeze,
> > i added some features.
> >
> > - smp aware
> > - clickless connections
> 
> Is there any reason why a user would prefer this over jack2?

i am not sure, but there a several users which report xruns with jack2,
where jack1 still works.
though i am not sure if they tested jack 1.9.4 which seem ok in sync mode
at least. 

tschack still has most properties of jack1

> 
> 
> Chris

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] tschack ... early version of smp enabled jack1

[torbenh]

On Tue, Jan 26, 2010 at 07:38:38AM -0800, James Warden wrote:
> 
> 
> --- On Tue, 1/26/10, Chris Cannam  wrote:
> 
> > From: Chris Cannam 
> > Subject: Re: [LAD] tschack ... early version of smp enabled jack1
> > To: "torbenh" 
> > Cc: linux-audio-dev@lists.linuxaudio.org
> > Date: Tuesday, January 26, 2010, 7:38 AM
> > On Sun, Jan 24, 2010 at 9:05 PM,
> > torbenh 
> > wrote:
> > > since i dont want to let jack1 codebase die in a
> > feature freeze,
> > > i added some features.
> > >
> > > - smp aware
> > > - clickless connections
> > 
> > Is there any reason why a user would prefer this over
> > jack2?
> > 
> 
> and would I assume correctly that one of the reasons to not let the jack1 
> codebase "die" (or freeze)  is that it is written in C as opposed to jack2 ?

no. i actually prefer C++
but not that much that i would deal with CamelCase and a class hierarchy
i find confusing. but thats just my taste. 


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] hard realtime performance synth

[torbenh]

On Thu, Jan 28, 2010 at 03:01:38PM -0500, David McClanahan wrote:
> On Tue, Jan 26, 2010 at 8:47 PM, David Olofson  wrote:
> 
> 
> > Now, in real life, the "every time" part will never be quite accurate.
> > After
> > all, you may see some "once in a billion" combination of hardware events
> > that
> > delays your IRQ a few microseconds too many, or your lose power, or the
> > hardware breaks down, or a software bug strikes... There are countless
> > things
> > that can go wrong in any non-trivial system.
> >
> > Even in HRT systems, things go wrong. But in an HRT system, you lash the
> squirrels nuts down. In a soft realtime system, you bet that there won't be
> a storm.

i still dont understand how building a highway, can speed up a bicycle
with a flat tire.

you should try a car on a normal road. will get you where you want.

> 
> 
> 
> > Of course, there's a big difference between a DAW that drops out a few
> > times a
> > day, and one that runs rock solid for weeks - but a truly glitch-free
> > system
> > would probably be ridiculously expensive, if it's even possible to build.
> > Triple redundancy hardware, code verified by NASA, various other things
> > I've
> > never even thought of; that sort of stuff...
> >
> > Who wants a DAW. I'd be happy a while  with a stable minimoog emulator. The
> Bristol has that and CS80(descendant of Yamaha's GX-1). It'd be cool just to
> have a stable, glitch a day, analog-like synth such as these. As it is now
> with Ubuntu's Studio packages, Bristol locks up  and then locks up the
> operating system as does Zyn. FluidSynth works but will glitch quite a bit.

you named the set of synths which are not RT safe.
(i dont really know about fluidsynth, but zyn and especially bristol
arent clean)

thats what i meant with bicycle.

> >
> > Well I understand it from that perspective, but for a performance
> instrument I would think no buffering would be the ideal.

we are talking about a buffer of 3ms here.
sound travels about 1 meter in that time.



-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Anyone testing the new TerminatorX release?

[torbenh]

On Mon, Feb 01, 2010 at 11:03:04AM +0100, gerald mwangi wrote:
> I didn't consider this point, and its truly one to think about. But
> since major projects also use sndfile and mad (like ardour uses
> sndfile), and the use of them simplifies the code, I still favour them
> over using external apps. 
> 
> Another thing, we should better open a sourceforge project for tX with
> svn. 

svn ? this is so 200x


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] CV data protocol in apps.

[torbenh]

On Thu, Feb 18, 2010 at 11:30:42AM +0100, Julien 'Lta' BALLET wrote:
> Hello,
> 
> That's true, this isn't new at all. but it has been lost for some
> times in the audio world in favor of midi, mainly afaik because too
> much cables just drives people crazy :)
> 
> But actually, implementing it perfectly it jack apps may cost a lot if
> your control rate is the same as the audio rate (for example computing
> a filter coefs 96000 times per second). I think a new type of 'audio'
> port having only a sample per period could be a simple and handy

dunno. but i think timestamped events are better.
maybe we should just specify some 32bit/float midi replacement ?

iE somthing that can be translated down to midi.
but still has float values.

an event consisting of uint32_t and a float
could encode all sorts of stuff.

2^24 float CC
21 octaves with 1/65536 tones. noteon noteoff with float velocity.
still got 253 eventtypes free

all in a nice 8byte per event thingy.

of course it would be discussed to death :(


> solution to this (one of the problem may be when you connect more than
> one cv to a port, mixing CV isn't necessarily the thing we want to do)
> 
> Anyway, CV is still, even after 50 year, a really nice way of
> controlling audio parameters, and would be kind of a good solution for
> mapping lv2 control ports to jack ports.
> 
> Regards,
> Lta.
> 
> 2010/2/18 Jörn Nettingsmeier :
> > On 02/18/2010 10:54 AM, alex stone wrote:
> >> As a power user who's modestly (just kidding) keen on saving time,
> >> using great workflow, and avoiding as much of the drudgery of editing
> >> work over and over again to get an end result as is possible, i've had
> >> the privilege and pleasure of testing and working with a data protocol
> >> called CV, or control voltage, in these last 2 weeks.
> >
> > funny to call CV a "protocol" - it's been around since the 60s, and just
> > describes the fact that a given processing unit reacts to an incoming
> > voltage rather than a knob.
> >
> > at first, i wasn't quite sure if you're joking... but yes, it's very
> > convenient, just totally not new :)
> >
> > much like a "one midi command per wire, running status on" architecture.
> >
> > compared to ardour's automation tracks (which are somewhat difficult to
> > use), what does non-mixer do that's better?
> > comparing midi and cv is apples and oranges imho.
> >
> >
> >
> >
> > ___
> > Linux-audio-dev mailing list
> > Linux-audio-dev@lists.linuxaudio.org
> > http://lists.linuxaudio.org/listinfo/linux-audio-dev
> >
> 
> 
> 
> -- 
> BALLET Julien
> Head of LabFree,  Free software laboratory of Epitech
> Phone : 01 53 14 59 32 || 06 17 32 86 93.
> Mail :  -- 
> Web : http://www.labfree.org/
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] CV data protocol in apps.

[torbenh]

On Thu, Feb 18, 2010 at 02:18:54PM +0300, alex stone wrote:
> I will clarify here that i'm talking about a user experience, before
> the discussion gets into jousting with white papers.
> 
> :)

hmm... i guess this was some thread hijack.
anyways. my papers are generally brown, because i spilled coffee over
them.

> 
> Alex.
> 
> 
> 
> 
> -- 
> www.openoctave.org
> 
> midi-subscr...@openoctave.org
> development-subscr...@openoctave.org
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] CV data protocol in apps.

[torbenh]

On Thu, Feb 18, 2010 at 02:18:54PM +0300, alex stone wrote:
> I will clarify here that i'm talking about a user experience, before
> the discussion gets into jousting with white papers.

ok. so you basically say that midi channels are annoying ?
how about several CC controllers flowing through the same midi connection ?
you think thats bad too ?

i mean for complex synths this could quickly end up in 20 CV lines
controlling one voice.


> 
> :)
> 
> Alex.
> 
> 
> 
> 
> -- 
> www.openoctave.org
> 
> midi-subscr...@openoctave.org
> development-subscr...@openoctave.org
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] CV data protocol in apps.

[torbenh]

On Thu, Feb 18, 2010 at 06:09:42PM +0100, f...@kokkinizita.net wrote:
> On Thu, Feb 18, 2010 at 11:43:07AM -0500, Paul Davis wrote:
> 
> > On Thu, Feb 18, 2010 at 11:32 AM,   wrote:
> >
> > > A reduced sample rate means less bandwidth. It doesn't mean
> > > that controls can't be 'sample accurate'. You could even
> > > extract 'sub-sample-accurate' discrete events from them,
> > > it's just a matter of interpretation.
> > 
> > this just needs a minor re-use of the existing midi port type.
> > drobilla always felt that it was questionable that we called this
> > stuff "midi" at all, because 95% of the infrastructure is about
> > handling sample accurate events, and is utterly agnostic about the
> > contents.
> 
> We may not be talking of the same thing. This is not about
> 'generic events' but about reduced-bandwidth continuous
> signals, represented as floating point samples. So I'd say
> that all it takes is a shorter version of the standard
> _audio_ buffer.

could you define _shorter_
is that app specific. or would that be a single factor for the whole
jack graph ?

if we dont mandate that a jack period is always an integer multiple
of a period, we basically need some phase association.
so that apps can sort of know that CV sample 0 has the same time
as audio_sample[phase]


> 
> The last paragraph in my previous post just hinted at the
> possibility that even such low-bandwidth 'analog' signals
> can represent discrete events with infinite timing accuracy,
> and in a way that would e.g. survive operations such as
> mixing or resampling. 

hmm... its not completely obvious to me how it could survive
some arbitrary resampling.

i am thinking of:
x[0] = 0;
x[1] = 0.75;
x[N] = 1.0  | N>1
to encode an event to switch from 0 to 1 at t=0.66

(this representation is not causal, so it would need to be shifted...
but this is what i have in mind)

i am a bit wary because this still seems a lot more expensive than
having timestamped float events. and i am not sure the ease of recording
this kind of data weighs it up again.


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] CV data protocol in apps.

[torbenh]

On Fri, Feb 19, 2010 at 02:42:36PM +0100, Fons Adriaensen wrote:
> On Fri, Feb 19, 2010 at 04:05:02PM +0300, alex stone wrote:
> 
> > An obvious question i guess, but is 1/16 a fine enough resolution for
> > a wide selection of use cases?
> 
> I don't know about any 'human interfaces' (faders, knobs,
> mouses, touchscreens, acceleration sensors, whatever) that
> can generate 1000Hz control signals. 

gamer mouse :)

/me hides.


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] CV data protocol in apps.

[torbenh]

On Fri, Feb 19, 2010 at 01:48:24PM +0100, Fons Adriaensen wrote:
> On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh wrote:
> 
> > On Thu, Feb 18, 2010 at 06:09:42PM +0100, f...@kokkinizita.net wrote:
> >
> > > We may not be talking of the same thing. This is not about
> > > 'generic events' but about reduced-bandwidth continuous
> > > signals, represented as floating point samples. So I'd say
> > > that all it takes is a shorter version of the standard
> > > _audio_ buffer.
> > 
> > could you define _shorter_
> > is that app specific. or would that be a single factor for the whole
> > jack graph ?
> 
> Apps using this may have a preference, but I see no difficulty
> in defining the a fixed control/audio ratio of 1/16. 
> The intended use is to patch control signals, e.g. source
> positions in a spatialisation system, or more classical
> automation data such as gains and filter paramaters.
> 1/16 would provide a bandwidth of 1500 Hz (for a sample
> rate of 48000) which is some overkill in many cases, but
> otherwise good to have.

good point. ok. so this still leaves us with the problem of the phase
relation in case of non-power of 2 period sizes.
(i am not sure if this patch slipped into jack1 accidentally or on
purpose, but the alsa driver doesnt enforce power of 2 anymore)

but that kind of thing can be fixed easily.
jack_nframes_t jack_cv_get_phase( jack_client_t *client );


i am basically more in favour of timestamped events.
but your argumentation in this thread is pretty convincing.
and timestamped events come with a galore of other problems,
which i think are harder to tackle in a jack context.

- multiple interpolation schemes
- how to get the current value when port is connected, and didnt see an
  event yet.

so what do people think ? 
shall we just add CV port type ?
(this would sort of rule out timestamped control events, since there
should be only one control port type)





> 
> > if we dont mandate that a jack period is always an integer multiple
> > of a period, we basically need some phase association.
> > so that apps can sort of know that CV sample 0 has the same time
> > as audio_sample[phase]
> 
> With a ratio of 1/16 you can just define the first sample
> of control buffer to coincide with the first sample of 
> the current audio period.

not if the period is not a power of 2 :(
but maybe we should just go back to enforcing that again.


>  
> > hmm... its not completely obvious to me how it could survive
> > some arbitrary resampling.
> > 
> > i am thinking of:
> > x[0] = 0;
> > x[1] = 0.75;
> > x[N] = 1.0  | N>1
> > to encode an event to switch from 0 to 1 at t=0.66
> > 
> > (this representation is not causal, so it would need to be shifted...
> > but this is what i have in mind)
> 
> You're close, see below. 

thanks for explanation :)

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] For your information

[torbenh]

On Sat, Feb 20, 2010 at 11:22:38PM +0100, f...@kokkinizita.net wrote:
> To all, for your information.
> 
> I have received the following message from Mr. Nick Copeland.
> It was sent privately, but since this is the continuation of 
> a thread on this list and the person concerned has well gone
> beyond any reasonable limits of decent behaviour I feel free
> to post it here.

lol...
how did you earn that ?
by saying that bristol sucks ?

anyways. since the mail fons wrote is missing, i cant say whos mistake
it was. 
nick seem to be referring to this:
http://alsamodular.cvs.sourceforge.net/viewvc/alsamodular/ams/m_vcf.cpp?hideattic=0&revision=1.1&view=markup

however if m_vcf.c was any good the example patches wouldnt be using
fonss ladspas. 
and i remember mathias nagorni showing me totally enthuasistically
the MCP filters. 



> 
> *** Start included message ***
> 
> The last time I looked at the AMS source code I was under the impression
> that the Moog VCF filters were not actually yours, they were Tossavainen
> and Kellets. They were published eventually placed on musicdsp.org however
> there are a couple of things here:
> 
> 1. In their original publishing they did not advocate the use of
> quantisation of their parameters - you implemented this as an
> adaptation of their algorithm.
> 
> 2. In not quoting the original authors you are plagiarism them.
> In the source to AMS they are quoted however it is bit disingenious
> to imply that this was 'your' MoogVCF.
> 
> In short you did not actually write the 'Moog' VCF parts and
> suggesting that this is how their algorithms worked is just
> attempting to justify quantisation to 1/16 is not deleterious
> to quality which is definitely not attributable to the original
> authors.
> 
> >>From what you are saying I would like to just say you are an
> arrogant selfpublicist however base on the claims in your email
> you are actually a lying plagiarst.
> 
> Regards nick.
> 
> *** End included message ***
> 
> -- 
> FA
> 
> O tu, che porte, correndo si ?
> E guerra e morte !
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] For your information

[torbenh]

On Sun, Feb 21, 2010 at 12:13:33AM +0100, Nick Copeland wrote:
> 
> Hi Fons,
> 
> Both of these are your quotes from your last two email. These might
> have been directly to me however you chose to take it on to the list:
> 
> > BTW, the code I referred to is a set of plugins, it is not part of AMS.
> >> Returning to 'cutting corners', my MoogVCF filter is also
> >> regarded as one of the best. It operates a described
> >> above - it cuts a lot of corners, and certainly does not
> >> accept audio rate control, even if the interface is at
> >> audio rate (as is everyhting in AMS for which it was
> >> written).As I just reponded to you directly, but as you seem to want to 
> >> make this
> public for reasons that I truly don't understand, let me put this one back
> on the list.
> 
> You did not write the MoogVCF filter for AMS. You may have adapted
> other peoples work, acknowledging that one thing, but let us be honest
> here, trying to take credit for their work is plagiarism.
> 
> The code that you evidently did not write which was not a part of AMS
> (according to you) was a part of AMS (also according to you). So again, 
> either you are a liar, or a self publicist, and either way, your claim to
> me that it was 'your MoogVCF' is plagiarism and that was part of my
> private email to you,

what are you trying to say ?
he said he wrote a ladspa plugin.
and he wrote it "for" ams, because it uses ams CV conventions for
frequency.
so the major usecase for this plugin is "being used in ams".

lets argue that people just stuck the schematic for a moog filter into a
bilinear transform and take the credit which belongs to mr. moog.
oh wait ... they all name the filter moog filter.



> 
> Kindest regards, nick.
> 
> "we have to make sure the old choice [Windows] doesn't disappear”.
> Jim Wong, president of IT products, Acer
> 
> 
> 
> 
> From: nickycopel...@hotmail.com
> To: f...@kokkinizita.net; linux-audio-dev@lists.linuxaudio.org
> Date: Sat, 20 Feb 2010 23:36:04 +0100
> Subject: Re: [LAD] For your information
> 
> 
> 
> 
> 
> 
> 
> 
> Hi Fons,
> 
> You are welcome to post this on LAD. I would have done so as well except 
> if you remember from your original reply, it was directly to me and not the
> list, so I thought I would be similarly respectful and only send my response
> back to you,
> 
> Kindest regards, nick.
> 
> "we have to make sure the old choice [Windows] doesn't disappear”.
> Jim Wong, president of IT products, Acer
> 
> 
> 
> 
> > Date: Sat, 20 Feb 2010 23:22:38 +0100
> > From: f...@kokkinizita.net
> > To: linux-audio-dev@lists.linuxaudio.org
> > Subject: [LAD] For your information
> > 
> > To all, for your information.
> > 
> > I have received the following message from Mr. Nick Copeland.
> > It was sent privately, but since this is the continuation of 
> > a thread on this list and the person concerned has well gone
> > beyond any reasonable limits of decent behaviour I feel free
> > to post it here.
> > 
> > *** Start included message ***
> > 
> > The last time I looked at the AMS source code I was under the impression
> > that the Moog VCF filters were not actually yours, they were Tossavainen
> > and Kellets. They were published eventually placed on musicdsp.org however
> > there are a couple of things here:
> > 
> > 1. In their original publishing they did not advocate the use of
> > quantisation of their parameters - you implemented this as an
> > adaptation of their algorithm.
> > 
> > 2. In not quoting the original authors you are plagiarism them.
> > In the source to AMS they are quoted however it is bit disingenious
> > to imply that this was 'your' MoogVCF.
> > 
> > In short you did not actually write the 'Moog' VCF parts and
> > suggesting that this is how their algorithms worked is just
> > attempting to justify quantisation to 1/16 is not deleterious
> > to quality which is definitely not attributable to the original
> > authors.
> > 
> > >From what you are saying I would like to just say you are an
> > arrogant selfpublicist however base on the claims in your email
> > you are actually a lying plagiarst.
> > 
> > Regards nick.
> > 
> > *** End included message ***
> > 
> > -- 
> > FA
> > 
> > O tu, che porte, correndo si ?
> > E guerra e morte !
> > ___
> > Linux-audio-dev mailing list
> > Linux-audio-dev@lists.linuxaudio.org
> > http://lists.linuxaudio.org/listinfo/linux-audio-dev
> 
> Hotmail: Trusted email with powerful SPAM protection. Sign up now.
>   
> _
> Hotmail: Free, trusted and rich email service.
> https://signup.live.com/signup.aspx?id=60969

> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev


-- 
torben Hohn
___
Linu

Re: [LAD] ambisonics UHJ encoder

[torbenh]

On Tue, Feb 23, 2010 at 10:58:54PM +0100, Jörn Nettingsmeier wrote:
> hi alex, fons!
> since you are dealing with artificial sources anyways, why stick to
> first order? do your panning in higher order instead. the use of
> resources is minimal (although it will create an insane amount of jack
> ports, so use -P2048). it won't make any difference to your UHJ, since
> it only ever sees WXY, but it would enable you to produce really crisp
> n.1 or HOA decodes without any extra work.

since he already uses -P2048 i guess, its -P8192 or even higher now :D

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] wanted: good online reading material for RT audio/midi software design?

[torbenh]

On Thu, Feb 25, 2010 at 01:00:34AM -, James Morris wrote:
> On Wed, February 24, 2010 23:15, Harry Van Haaren wrote:
> 1) MODEL:
> jack_process callback - where midi data is output, timebase polled,

the model is a datastructure.
its the sequence or data that is your document.

> 
> 2) VIEW:
> the gui - where the user controls generation of notes and is shown notes
> that play

additionally the process_thread could be considered a view too.
this view is a linear view, which only sees short parts of the model.
so generally you can get away with providing a copy of the model.


> 
> 3) CONTROLLER:
>  i)  time pattern: 1d - note position & duration
>  ii) pitch pattern: 2d - pitch & velocity

controllers modify your model.
if your model has a bit of complexity, you cant share your model in a
lockfree manner between the 2 views.

so basically both views must own a copy of the model. and you need to
figure out a way to apply controllers to both copies of the model.

or use rcu techniques, to modify one copy of the model. and then do
an atomic exchange.


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Integrate LASH into Jack

[torbenh]

On Fri, Mar 05, 2010 at 11:48:11AM +0100, Gerald Mwangi wrote:
> Hi, this is a part of a previous mail,but with catchier Subject
> 
> I think LASH should be integrated into Jack, to make it mandatory for
> linux audio apps. The missing LASH support is one of the main issues
> disturbing me, when working with linux audio. Now I've said it, ha. 
> I'm thinking of having Jack require a Load/Save callback, prior to
> activating the client. How feasible is that? 
> What do you think?
> Gerald

i think this: 
http://hochstrom.endofinternet.org/cgit/jack.git/tree/jack/session.h?h=jack-session2


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jack daemon scripts

[torbenh]

On Mon, Mar 08, 2010 at 01:14:52AM +0300, alex stone wrote:
> On Mon, Mar 8, 2010 at 12:25 AM,   wrote:
> > On Mon, Mar 08, 2010 at 04:32:39AM +0800, Ray Rashif wrote:
> >
> >> After further testing, it appears JACK_PROMISCUOUS_SERVER no longer
> >> works. Paul, is that intentional?
> >
> > Indeed it doesn't. There's at least one error in
> > /etc/conf.d/jack-audio-connection-kit: the '-d'
> > in the driver options leads to a double '-d' in
> > the final command line. But that isn't the reason
> > things don't work.
> >
> > It should be noted that Archlinux provides the
> > script in /etc/rc.d but does not in any way use
> > it unless the user takes action (that is normal
> > Arch policy, if you want any daemons you have to
> > add them manually to /etc/rc.conf). So far I was
> > completely unaware of its existence.
> >
> > I'd be *VERY HAPPY* if jackd could be used as
> > a system daemon, with e.g. access limited to
> > members of a the audio group. Or even unlimited.
> > It would simplify things here *A LOT*.
> >
> > Ciao,
> >
> > --
> > FA
> >
> > O tu, che porte, correndo si ?
> > E guerra e morte !
> > ___
> > Linux-audio-dev mailing list
> > Linux-audio-dev@lists.linuxaudio.org
> > http://lists.linuxaudio.org/listinfo/linux-audio-dev
> >
> 
> Out of curiosity, what's the pros and cons of using jackd as a system daemon?

first of all its not tested. and it doesnt work.
thats only a problem with permissions though
after some chmod on /dev/shm/jack running jack_lsp as nobody works.
but the patch needs to be either removed or fixed. 

second, and more important reason. jack isnt designed to be secure in
any way. a malicious client can easily make jackd crash. and since its
possible to write data into the servers addressspace, its pretty likely
that its possible to make this crash execute code with jackd privilege
level. 

otoh there are probably enough other local root exploits, so i guess
this doesnt really matter. and a system where normal untrusted users
get handed RT privileges is doomed anyways :)

so basically as long as you trust your users to the point that they dont
want to hack into the system, its probably ok.


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jack daemon scripts

[torbenh]

On Mon, Mar 08, 2010 at 11:43:53AM +0100, Arnold Krille wrote:
> While I understand the fun of running jackd as root as a system service...

i am actually not talking about jackd running as root.
but any user who has access to it, can shoot it down. 

> 
> On Monday 08 March 2010 03:06:08 torbenh wrote:
> > otoh there are probably enough other local root exploits, so i guess
> > this doesnt really matter. and a system where normal untrusted users
> > get handed RT privileges is doomed anyways :)
> 
> There is more at stake here: There are these nice network things in jack, so 
> this makes your "local root exploit" (which is bad enough in its own) a 
> "network root exploit". If your alarm bells aren't ringing here, you probably 

what network things ?
do you mean netjack ? 
thats a pretty different piece of cake. 


> run your machine without any connection to the outside world (no network, 
> usb, 
> floppy, cdrom/dvd)...
> 
> > so basically as long as you trust your users to the point that they dont
> > want to hack into the system, its probably ok.
> 
> What about running jackd as user "nobody" and allowing all in the audio group 
> to connect?
> Trusting "everybody" can go wrong way to fast to even think about it.
> 
> Oh, please, please don't ever mention running jackd as root again. Yes, it 
> might "fix" some problems. But finding these "fixes" in the archives leads to 
> many innocent googling starters to the dark side of the audio force.

i am not talking about running jackd as root.
(thats not the idea of PROMISCUOUS patch anyways)




> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jack daemon scripts

[torbenh]

On Mon, Mar 08, 2010 at 12:22:50PM +0100, f...@kokkinizita.net wrote:
> On Mon, Mar 08, 2010 at 03:06:08AM +0100, torbenh wrote:
> 
> > second, and more important reason. jack isnt designed to be secure in
> > any way. a malicious client can easily make jackd crash. and since its
> > possible to write data into the servers addressspace, its pretty likely
> > that its possible to make this crash execute code with jackd privilege
> > level. 
> 
> This risk always exists once you allow a user to use Jack,
> it doesn't matter if that happen under his own login (as
> would be permitted with promiscuous) or using a second
> 'shared' identity (as is required now if there is more
> than one user). The latter is probably even less safe.
> 
> And at least here, a computer being hacked is probably
> the least of all risks. Any user getting access to the
> system can damage it in much more expensive ways.
> 
> Allowing access based on group membership would be ideal,
> at least for my use.

all that is needed is fixing up the permissions of the files
jackd creates in /dev/shm/jack

its pretty possible that umask( 0002 );  would fix this.
then just make sure the user under which jackd is running has his
primary group set to audio

i am talking about jack1 here. 
tschack has promiscous mode too.

i am not aware of this functionality in jack2.

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jack daemon scripts

[torbenh]

On Tue, Mar 09, 2010 at 01:02:13PM +0800, Ray Rashif wrote:
> On 08/03/2010, torbenh  wrote:
> > first of all its not tested. and it doesnt work.
> > thats only a problem with permissions though
> > after some chmod on /dev/shm/jack running jack_lsp as nobody works.
> > but the patch needs to be either removed or fixed.
> 
> It looks like the promiscuous part of the code hasn't changed:
> http://trac.jackaudio.org/changeset/1028
> 
> So it should still work, but for some reason connections aren't
> getting through, although jackd is setting the correct permissions for
> /dev/shm/$jacktmpdir..a test case I ran by creating a normal user
> "audio":
> 
> [r...@localhost ~] # useradd -N -K SYS_UID_MAX=499 -K SYS_GID_MAX=499
> -s /bin/bash -g audio -G users,video,network -c audio -d /var/lib/jack
> audio
> 
> [r...@localhost ~] # mkdir -p /var/lib/jack && chown audio:audio /var/lib/jack
> 
> [r...@localhost ~] # su - audio -c 'umask  && export
> JACK_PROMISCUOUS_SERVER && jack -P55 -dalsa -dhw:0 -r48000 -p512 -n3'
> *** server start success ***
> 
> [r...@localhost ~] $ ls -l /dev/shm
> total 0
> drwx-- 3 audio audio 60 Mar  9 12:35 jack-1001
> 
> Perms are not correct, so try again with JACK_PROMISCUOUS_SERVER="":
> 
> [r...@localhost ~] # killall jackd && su - audio -c 'umask  &&
> export JACK_PROMISCUOUS_SERVER="" && jack -P55 -dalsa -dhw:0 -r48000
> -p512 -n3'
> *** server start success ***
> 
> [r...@localhost ~] $ ls -l /dev/shm
> total 0
> drwxrwxrwx 3 audio audio 60 Mar  9 12:40 jack
> 
> [r...@localhost ~] $ ls -l /dev/shm/*/*
> total 0
> prw-rw-rw- 1 audio audio 0 Mar  9 12:40 jack-ack-fifo-28335-0
> prw-rw-rw- 1 audio audio 0 Mar  9 12:40 jack-ack-fifo-28335-1
> srwxrwxrwx 1 audio audio 0 Mar  9 12:40 jack_0
> srwxrwxrwx 1 audio audio 0 Mar  9 12:40 jack_ack_0
> 
> Perms are now correct, so try starting a client with another user "foo":

this looks good, and will work.
you needs to set JACK_PROMISCUOUS_SERVER for all clients also.


> 
> [...@localhost ~] $ mplayer -ao jack awesome.wav
> ...
> ...
> [JACK] cannot open server
> Failed to initialize audio driver 'jack'
> Could not open/initialize audio device -> no sound.
> Audio: no sound
> Video: no video
> 
> 
> Exiting... (End of file)
> 
> And from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500249:
> 
> "Cause there's no system-wide jackd anymore, it can't be promiscuous."
> 
> 
> --
> GPG/PGP ID: B42DDCAD
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Freqtweak & gcc 4.4

[torbenh]

On Sat, Mar 20, 2010 at 02:18:13PM +1100, Erik de Castro Lopo wrote:
> Jesse Chappell wrote:
> 
> > I'm still around,
> 
> Oh, good!
> 
> > but oh man, I've been neglecting freqtweak for
> > years.  If distro maintainers ever notified me about anything I might
> > actually be prompted to spend the few hours getting everything back in
> > order.  Even sooperlooper has been neglected for too long.  Yes, I
> > need to update to sigc++2 quite badly.
> > 
> > For those who wonder what I have been doing in my audio software
> > spare-time, check out http://thumbjam.com .
> > 
> > In the meantime I really will try to update FT soon.
> 
> Well maybe the first step would be to get it under revision control,
> preferably of the distriuted kind (Bzr, Darcs, Git, Mercurial etc).
> 
> The at least people can get your current version, polish it locally
> and send you patches.

i converted the cvs repo to git and switched the codebase to sigc-2.0
also fixed a few 64bit errors on the way.

it compiles and seems to work.
however there is no scrollbar at the side.
and i got a couple of wx deprecation warnings.

oh well...

git clone git://hochstrom.endofinternet.org/freqtweak.git

cgit is here:
http://hochstrom.endofinternet.org/cgit/freqtweak.git/



> 
> Cheers,
> Erik
> -- 
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Freqtweak & gcc 4.4

[torbenh]

On Sat, Mar 20, 2010 at 04:57:56PM +1100, Erik de Castro Lopo wrote:
> Erik de Castro Lopo wrote:
> 
> > I can only find CVS (which is truely horrible).
> 
> And the CVS version seems to be 0.7.1, while the last release was
> 0.7.2.

the diff between 0,7.2 and the cvs head is really small:
http://hochstrom.endofinternet.org/cgit/freqtweak.git/commit/?id=daafe19d2136f13d846c52f330c5ee4817256483


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] jack-session finally merged.

[torbenh]

hi...

jacksession stuff is merged into jack1 svn.

here is a rough explanation what needs to be done for apps to support
it: http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession

please let me know what is unclear.


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jack-session finally merged.

[torbenh]

On Fri, Mar 26, 2010 at 07:41:35PM +0100, rosea grammostola wrote:
> On Fri, Mar 26, 2010 at 7:04 PM, torbenh  wrote:
> 
> >
> > hi...
> >
> > jacksession stuff is merged into jack1 svn.
> >
> > here is a rough explanation what needs to be done for apps to support
> > it: http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession
> >
> > please let me know what is unclear.
> >
> 
> 
> When will it hit jack2?

paniq said he wanted to implement it for jack2. 

> 
> What are your plans for an session manager, cause so far it's only the API
> right? I mean, you wouln't implement this api if there where not plans for
> making a real great session manager, right?

i have a sessionmanager i used for testing. 

git clone git://hochstrom.endofinternet.org/pyjacksm.git

it doesnt have a gui yet. only a commandline interface.
that said, jsweeper has a gui for it.



> 
> Good luck with the project!
> 
> \r

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jack-session finally merged.

[torbenh]

On Sat, Mar 27, 2010 at 08:10:51PM +0100, Philipp wrote:
> Excerpts from rosea grammostola's message of 2010-03-27 19:50:22 +0100:
> > jsweeper?
> > 
> > \r
> > 
> I also wonder where it can be found.

svn co http://svn.fuzzle.org/jsweeper/trunk jsweeper


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jack-session finally merged.

[torbenh]

On Sun, Mar 28, 2010 at 12:31:10PM +1100, Patrick Shirkey wrote:
> 
> 
> On 03/28/2010 12:24 PM, Harry Van Haaren wrote:
> > Hi,
> >
> > Thank you for the effort you've put into this. I havent even tried it 
> > yet, (will do so
> > when I get some time), however as a Lin-Audio user, I really 
> > appreciate this work.
> >
> > I will read the API, and if I understand enough of it, I will code 
> > support for these
> > features.
> >
> 
> 
> 
> Yesterday I tried to quickly whip up a demo app. I got into it for an 
> hour but couldn't decide if it was worth adding all the gui features 
> necessary for a simple demo.
> 
> So far I came up with an app that load a gtk window with two buttons and 
> four sliders.
> 
> button1: Save Session
> button2: quit session

there is no standard way to trigger a Session Save.
it will be session manager dependent.

pyjacksm has a dbus interface. but i wouldnt consider it stable as of
yet.

> 
> slider 1 = channel 1, slider 2 = channel 2 etc...
> 
> When save session/quit session are pressed the app saves the position of 
> the sliders to a file on disk and loads it again when started if it exists.
> 
> As a simple app it won't really do anything useful apart from demo how 
> to work with the code so I would like to get some feedback from other 
> users on what would actually be a useful demo of the code in action.
> 
> I'm thinking along the lines of the demos apple released for the iphone 
> which while being mostly fairly unnecessary are also still perfectly 
> functional apps in their own right.
> 
> If I can remove widgets or add only a couple more that would be preferable.

i dont really see the relation to jack session.
only 10% of such an app would be jack session related. 
i dont really think would be a good demo of jack-session.

but maybe i am wrong.
i tend to think that patches which add session support are better
examples.

this is the patch for seq24:
http://trac.jackaudio.org/attachment/wiki/WalkThrough/User/jack_session/jack-session.patch


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jack-session finally merged.

[torbenh]

On Sun, Mar 28, 2010 at 10:07:48PM +1100, Patrick Shirkey wrote:
> 
> 
> On 03/28/2010 09:32 PM, torbenh wrote:
> > On Sun, Mar 28, 2010 at 12:31:10PM +1100, Patrick Shirkey wrote:
> >
> >>
> >> On 03/28/2010 12:24 PM, Harry Van Haaren wrote:
> >>  
> >>> Hi,
> >>>
> >>> Thank you for the effort you've put into this. I havent even tried it
> >>> yet, (will do so
> >>> when I get some time), however as a Lin-Audio user, I really
> >>> appreciate this work.
> >>>
> >>> I will read the API, and if I understand enough of it, I will code
> >>> support for these
> >>> features.
> >>>
> >>>
> >>
> >>
> >> Yesterday I tried to quickly whip up a demo app. I got into it for an
> >> hour but couldn't decide if it was worth adding all the gui features
> >> necessary for a simple demo.
> >>
> >> So far I came up with an app that load a gtk window with two buttons and
> >> four sliders.
> >>
> >> button1: Save Session
> >> button2: quit session
> >>  
> > there is no standard way to trigger a Session Save.
> > it will be session manager dependent.
> >
> > pyjacksm has a dbus interface. but i wouldnt consider it stable as of
> > yet.
> >
> >
> 
> 
> This will no doubt lead to some confusion. Is there a recommended way of 
> handling the session save/quit operation in app? Or should we all just 
> leave that to the SM app and just add support for receiving the 
> notification in app?

until there crystalizes a standard api to talk to sessionmanagers i
think it would be wiser to leave this out of apps for now.

just add support for the session_event.

> 
> 
> >> slider 1 = channel 1, slider 2 = channel 2 etc...
> >>
> >> When save session/quit session are pressed the app saves the position of
> >> the sliders to a file on disk and loads it again when started if it exists.
> >>
> >> As a simple app it won't really do anything useful apart from demo how
> >> to work with the code so I would like to get some feedback from other
> >> users on what would actually be a useful demo of the code in action.
> >>
> >> I'm thinking along the lines of the demos apple released for the iphone
> >> which while being mostly fairly unnecessary are also still perfectly
> >> functional apps in their own right.
> >>
> >> If I can remove widgets or add only a couple more that would be preferable.
> >>  
> > i dont really see the relation to jack session.
> > only 10% of such an app would be jack session related.
> > i dont really think would be a good demo of jack-session.
> >
> > but maybe i am wrong.
> > i tend to think that patches which add session support are better
> > examples.
> >
> > this is the patch for seq24:
> > http://trac.jackaudio.org/attachment/wiki/WalkThrough/User/jack_session/jack-session.patch
> >
> >
> >
> 
> 
> That's not a bad idea. If we get a few different apps with different 
> languages and UI kits to contribute patches and version numbers of the 
> working app we would have a very useful resource and saves having to 
> write a new app just for demo purposes.

i am trying to gather status of apps on this wiki page:
http://trac.jackaudio.org/wiki/WalkThrough/User/jack_session

> 
> I will contribute a patch for jackEQ which is c+gtk2 in the next few days.

nice. looking forward to it.

> 
> 
> 
> Cheers.
> .
> 
> 
> Patrick Shirkey
> Boost Hardware Ltd
> 
> 
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAA] [ANN] guitarix-0.07.0 release 'reloaded'

[torbenh]

On Sun, Mar 28, 2010 at 04:14:29PM +0200, hermann wrote:
> guitarix is a simple Linux Rock Guitar amplifier and is designed 
> to achieve nice thrash/metal/rock/blues guitar sounds. 
> Guitarix uses the Jack Audio Connection Kit as its audio backend 
> and brings in one input and two output ports to the jack graph. 

cool.

here is a jack-session patch. 


-- 
torben Hohn
diff --git a/src/gx_engine.cpp b/src/gx_engine.cpp
index daf8957..eb10c0a 100644
--- a/src/gx_engine.cpp
+++ b/src/gx_engine.cpp
@@ -63,7 +63,7 @@ float ffuse;
 float fskin;
 
 /* --- forward definition of useful namespace functions --- */
-void gx_engine_init()
+void gx_engine_init( const string *optvar )
 {
 	//- lock the buffer for the oscilloscope
 	const int frag = (const int)gx_jack::jack_bs;
@@ -95,7 +95,11 @@ void gx_engine_init()
 
 	midi.init(gx_jack::jack_sr);
 	faust_init(gx_jack::jack_sr);
-	gx_preset::gx_recall_main_setting(NULL, NULL);
+	if( !optvar[LOAD_FILE].empty() )
+		gx_preset::gx_recall_settings_file( optvar[LOAD_FILE] );
+	else
+		gx_preset::gx_recall_main_setting(NULL, NULL);
+
 	initialized = true;
 }
 
diff --git a/src/gx_globals.cpp b/src/gx_globals.cpp
index c93af1e..b09f0bf 100644
--- a/src/gx_globals.cpp
+++ b/src/gx_globals.cpp
@@ -237,7 +237,9 @@ const char* shell_var_name[] =
 	"GUITARIX2JACK_OUTPUTS1",
 	"GUITARIX2JACK_OUTPUTS2",
 	"GUITARIX2JACK_MIDI",
-	"GUITARIX_RC_STYLE"
+	"GUITARIX_RC_STYLE",
+	"GUITARIX2JACK_UUID",
+	"GUITARIX_LOAD_FILE"
 };
 }
 
diff --git a/src/gx_jack.cpp b/src/gx_jack.cpp
index 8073492..3f26845 100644
--- a/src/gx_jack.cpp
+++ b/src/gx_jack.cpp
@@ -53,6 +53,10 @@ using namespace std;
 
 #include "guitarix.h"
 
+#ifdef HAVE_JACK_SESSION
+#include 
+#endif
+
 using namespace gx_system;
 using namespace gx_engine;
 using namespace gx_jconv;
@@ -62,7 +66,7 @@ namespace gx_jack
 {
 
 //- pop up a dialog for starting jack
-bool gx_jack_init()
+bool gx_jack_init( const string *optvar )
 {
 	jack_status_t jackstat;
 	client_name = "guitarix";
@@ -73,8 +77,14 @@ bool gx_jack_init()
 
 	AVOIDDENORMALS;
 
+#ifdef HAVE_JACK_SESSION
 	// try to open jack client
-	client = jack_client_open (client_name.c_str(), JackNoStartServer, &jackstat);
+	if (! optvar[JACK_UUID].empty())
+
+	client = jack_client_open (client_name.c_str(), jack_options_t(JackNoStartServer | JackSessionID), &jackstat, optvar[JACK_UUID].c_str());
+	else
+#endif
+	client = jack_client_open (client_name.c_str(), JackNoStartServer, &jackstat);
 
 	if (client == 0)
 	{
@@ -85,7 +95,7 @@ bool gx_jack_init()
 		{
 			gx_print_warning("Jack Init", "jackd OK, trying to be a client");
 			usleep(50);
-			return gx_jack_init();
+			return gx_jack_init( optvar );
 		}
 
 		// start a dialog
@@ -163,6 +173,10 @@ void gx_jack_callbacks_and_activate()
 	jack_set_process_callback(client, gx_jack_process, 0);
 	jack_set_port_registration_callback(client, gx_jack_portreg_callback, 0);
 	jack_set_client_registration_callback(client, gx_jack_clientreg_callback, 0);
+#ifdef HAVE_JACK_SESSION
+	if (jack_set_session_callback)
+		jack_set_session_callback (client, gx_jack_session_callback, 0);
+#endif
 
 	//- register the midi input channel
 	midi_input_port =
@@ -355,16 +369,18 @@ void gx_jack_connection(GtkCheckMenuItem *menuitem, gpointer arg)
 {
 	if (gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM (menuitem)) == TRUE) {
 		if (!client) {
-			if (gx_jack_init()) {
-string optvar[NUM_SHELL_VAR];
-gx_assign_shell_var(shell_var_name[JACK_INP],  optvar[JACK_INP] );
-gx_assign_shell_var(shell_var_name[JACK_MIDI], optvar[JACK_MIDI] );
-gx_assign_shell_var(shell_var_name[JACK_OUT1], optvar[JACK_OUT1]);
-gx_assign_shell_var(shell_var_name[JACK_OUT2], optvar[JACK_OUT2]);
+			string optvar[NUM_SHELL_VAR];
+			gx_assign_shell_var(shell_var_name[JACK_INP],  optvar[JACK_INP] );
+			gx_assign_shell_var(shell_var_name[JACK_MIDI], optvar[JACK_MIDI] );
+			gx_assign_shell_var(shell_var_name[JACK_OUT1], optvar[JACK_OUT1]);
+			gx_assign_shell_var(shell_var_name[JACK_OUT2], optvar[JACK_OUT2]);
+			gx_assign_shell_var(shell_var_name[JACK_UUID], optvar[JACK_UUID]);
+
+			if (gx_jack_init(optvar)) {
 
 // initialize guitarix engine if necessary
 if (!gx_engine::initialized) {
-	gx_engine::gx_engine_init();
+	gx_engine::gx_engine_init( optvar );
 }
 gx_jack_callbacks_and_activate();
 gx_jack_init_port_connection(optvar);
@@ -855,6 +871,32 @@ void gx_jack_clientreg_callback(const char* name, int reg, void* arg)
 	}
 }
 
+#ifdef HAVE_JACK_SESSION
+static int gx_jack_session_callback_helper(gpointer data) {
+jack_session_event_t *event = (jack_session_event_t *) data;
+string fname( event->session_dir );
+fname += "guitarix.state";
+string cmd( "guitarix -U " );
+cmd += event->client_uuid;
+cmd += " -f ${SESSION_DIR}guitarix.state";
+
+saveStateToFile( fname );
+
+event->command_line = strdup( cmd.c_str() );
+
+jack_session_reply( client, event );
+
+jack

Re: [LAD] jack-session finally merged.

[torbenh]

On Sat, Mar 27, 2010 at 07:55:46PM +0100, rosea grammostola wrote:
> On Sat, Mar 27, 2010 at 7:50 PM, rosea grammostola <
> rosea.grammost...@gmail.com> wrote:
> 
> >
> >
> > On Sat, Mar 27, 2010 at 4:54 PM, torbenh  wrote:
> >
> >> On Fri, Mar 26, 2010 at 07:41:35PM +0100, rosea grammostola wrote:
> >> > On Fri, Mar 26, 2010 at 7:04 PM, torbenh  wrote:
> >> >
> >> > >
> >> > > hi...
> >> > >
> >> > > jacksession stuff is merged into jack1 svn.
> >> > >
> >> > > here is a rough explanation what needs to be done for apps to support
> >> > > it: http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession
> >> > >
> >> > > please let me know what is unclear.
> >> > >
> >> >
> >> >
> >> > When will it hit jack2?
> >>
> >> paniq said he wanted to implement it for jack2.
> >>
> >> >
> >> > What are your plans for an session manager, cause so far it's only the
> >> API
> >> > right? I mean, you wouln't implement this api if there where not plans
> >> for
> >> > making a real great session manager, right?
> >>
> >> i have a sessionmanager i used for testing.
> >>
> >> git clone git://hochstrom.endofinternet.org/pyjacksm.git
> >>
> >> it doesnt have a gui yet. only a commandline interface.
> >> that said, jsweeper has a gui for it.
> >>
> >>
> > jsweeper?
> >
> > \r
> >
> 
> And can you explain what you want with your SM?

save and load sessions.

> 
> What is the philosophy behind it, what do you want to achieve with it, what
> should a user be able to do with it? Which apps are expected to support it
> and what it the expectation in general about the support in apps for you SM?

the user will be able to save the state of all apps supporting the API
with a single command/click.
and will be able to reload it. no more maintaining of connection setup
scripts and all the hassle involved before.

regarding app support:

already patched apps:
- jack-rack
- ghostess
- specimen
- guitarix

in queue:
- ardour
- fst
- seq24


i expect most jack apps for which session support makes sense to support
the API sooner or later.

> Why do you think this SM will be an success?

session support cant be turned off by packagers without turning off jack
support. a lot of LASH enabled apps showed up in repos with lash support
disabled for example.

also this approach doesnt tie a users to a specific sessionmanager.
in this early state there are only jack_session_notify and pyjacksm
but i expect more session managers to show up during this year.


> 
> Thanks in advance,
> 
> \r

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jack-session finally merged.

[torbenh]

On Mon, Mar 29, 2010 at 05:07:03PM +0100, Rui Nuno Capela wrote:
> On Mon, 29 Mar 2010 17:00:01 +0200, torbenh  wrote:
> > 
> > regarding app support:
> > 
> > already patched apps:
> > - jack-rack
> > - ghostess
> > - specimen
> > - guitarix
> > 
> > in queue:
> > - ardour
> > - fst
> > - seq24
> > 
> > 
> > i expect most jack apps for which session support makes sense to support
> > the API sooner or later.
> > 
> 
> fwiw, qtractor svn trunk already has full jack-session support
> (qtractor-0.4.5.1542+)
> 
> highly experimental and untested though--any brave souls out there ?:)
> 
> nb. all lazy/artificial restrictions that plagued qtractor before have
> been dropped

cool. thanks. 

jack_set_session_callback is a weak symbol. please test if its not zero
before using it.

if(jack_set_session_callback)
   jack_set_session_callback( x, y, z )

theoretically you would need to test the other symbols too,
but they exist if jack_set_session_callback exists, and the codepath
is triggered by the callback, so that should be ok.

also please use ${SESSION_DIR} in the commandline string returned.
this allows the SM to move session dirs around.
it includes the directory separator.



-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAA] [ANN] guitarix-0.07.0 release 'reloaded'

[torbenh]

On Tue, Mar 30, 2010 at 12:03:07AM +0200, Andreas Degert wrote:
> 2010/3/29 torbenh :
> > On Sun, Mar 28, 2010 at 11:33:12PM +0200, Andreas Degert wrote:
> >>
> >>  - --quit doesn't work (unknown dbus command)
> >
> > yes. its not implemented yet.
> >
> >>  - --quitas saves but doesn't quit the application
> >
> > the patch doesnt obey quit. i mailed it a bit too fast.
> > sorry.
> >
> >>  - --quitas and --saveas only seem to save when called the first time with
> >>    a session name
> >
> > do you mean a specifying the same session name twice ?
> > the SM refuses to overwrite existing sessions.
> > it doesnt print the error code, i think.
> >
> > i really need to give pyjacksm some love. i was focussing on getting
> > a couple of apps patched, and mainly tested using
> >
> > jack_session_notify save /full/path/to/session_dir
> >
> > it should be working correctly in jack1 svn r3976
> >
> >
> >>
> >>  - --load gives an exception, but works after killing the daemon
> >
> > i will go over jacksm now.
> > in dbus mode there are some problems.
> >
> >>
> >>  - the saved command line contains -f ${SESSION_DIR}guitarix.state, but
> >>    SESSION_DIR doesn't end with a /. Is just the slash missing in the
> >>    command line or is the value of SESSION_DIR wrong (for now i have
> >>    added a "/") ?
> >
> > yes. the slash was missing from the replaced value.
> > fixed in jacksm git now.
> >
> > the separators are os dependent. and i wanted to leave them out of the
> > API as much as possible.
> 
> The current git version of jacksm works now for me. Guitarix also seems
> to work fine in a session, but i'm puzzled about weak linking. The function
> address (of jack_set_session_callback) is null depending on if its in 
> libjack.so
> or not when ld is run, but independent of the version of libjack.so.0 at
> runtime. It seems as if the address is always bound lazily at function call
> time, not when the function pointer is checked for 0 (means it crashes
> when session support is compiled in but the libjack used at runtime
> doesn't support it).

i cant reproduce this here.
when i switch to jack2, guitarix (with the patch i sent you) still works
fine.


-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jack-session finally merged.

[torbenh]

On Tue, Mar 30, 2010 at 10:48:49AM +0200, rosea grammostola wrote:
> torbenh wrote:
> >On Sat, Mar 27, 2010 at 07:55:46PM +0100, rosea grammostola wrote:
> >>On Sat, Mar 27, 2010 at 7:50 PM, rosea grammostola <
> >>rosea.grammost...@gmail.com> wrote:
> >>
> >>>On Sat, Mar 27, 2010 at 4:54 PM, torbenh  wrote:
> >>>
> >>>>On Fri, Mar 26, 2010 at 07:41:35PM +0100, rosea grammostola wrote:
> >>>>>On Fri, Mar 26, 2010 at 7:04 PM, torbenh  wrote:
> >>>>>
> >>>>>>hi...
> >>>>>>
> >>>>>>jacksession stuff is merged into jack1 svn.
> >>>>>>
> >>>>>>here is a rough explanation what needs to be done for apps to support
> >>>>>>it: http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession
> >>>>>>
> >>>>>>please let me know what is unclear.
> >>>>>>
> >>>>>When will it hit jack2?
> >>>>paniq said he wanted to implement it for jack2.
> >>>>
> >>>>>What are your plans for an session manager, cause so far it's only the
> >>>>API
> >>>>>right? I mean, you wouln't implement this api if there where not plans
> >>>>for
> >>>>>making a real great session manager, right?
> >>>>i have a sessionmanager i used for testing.
> >>>>
> >>>>git clone git://hochstrom.endofinternet.org/pyjacksm.git
> >>>>
> >>>>it doesnt have a gui yet. only a commandline interface.
> >>>>that said, jsweeper has a gui for it.
> >>>>
> >>>>
> >>>jsweeper?
> >>>
> >>>\r
> >>>
> >>And can you explain what you want with your SM?
> >
> >save and load sessions.
> >
> >>What is the philosophy behind it, what do you want to achieve with it, what
> >>should a user be able to do with it? Which apps are expected to support it
> >>and what it the expectation in general about the support in apps for you SM?
> >
> >the user will be able to save the state of all apps supporting the API
> >with a single command/click.
> >and will be able to reload it. no more maintaining of connection setup
> >scripts and all the hassle involved before.
> >
> Does it save and reload sessions / settings / songs of the applications?

thats what sessionmanagement is about. it will reproduce the saved state
as far as the apps support that.

> 
> Is it possible to load an application with the SM, with an certain
> setting / preset/ session?

i dont understand this question.
the SM only starts apps when you reload a session.

if you want to start an app just start it. via any means you like.

> 
> \r

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev