Re: [LAD] [LAU] Some new things to play with

[fons]

On Mon, Oct 11, 2010 at 01:37:16AM +0400, Oleg Ivanenko wrote:

> Your tools as always like katana -- lightweight, visually simple, and precise.

:-) But not intended to slice off someone's head :-)

Ciao,

-- 
FA

There are three of them, and Alleline.

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

Re: [LAD] [LAU] Some new things to play with

[fons]

On Mon, Oct 11, 2010 at 10:29:57PM +0200, Jostein Chr. Andersen wrote:

> > Zita-rev1: Stereo or Ambisonic reverb.
> 
> I tried it on a snare and did a test on a whole drum set, damn it sounds 
> good, 
> it to good to be true! I'm seldom satisfied with the reverbs I hear, but this 
> is amazing. The controls works exactly as expected should when I tweak them: 
> natural and responsive.

I didn't expect it to be used on drums, but if it sounds OK, why not !

> This two new additions fits perfect to what I consider to be the 
> philosophy of your eq-channel strip you kindly sent me: Great, musically 
> natural sound that does precise what I want and make my trust my ears again. 

Never let technology get in the way of your ears !!

Ciao,

-- 
FA

There are three of them, and Alleline.

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

Re: [LAD] Some new things to play with

[Fernando Lopez-Lezcano]

On 10/11/2010 07:35 AM, f...@kokkinizita.net wrote:

On Mon, Oct 11, 2010 at 03:47:43PM +0200, Robin Gareus wrote:

The commonly used target (autotools) is "make uninstall"
(not "make remove")


But I don't use autotools :-). It's easy to provide both.


It is just a common idiom and would be good to follow it.

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

Re: [LAD] Some new things to play with

[Philipp Überbacher]

Excerpts from Robin Gareus's message of 2010-10-11 15:47:43 +0200:
> On 10/11/10 14:33, f...@kokkinizita.net wrote:
> > On Mon, Oct 11, 2010 at 01:02:09PM +0200, Robin Gareus wrote:
> > 
> >> Are they also available from some repository (svn, git,..)?
> > 
> > No. Most projects here are in svn and I'm exploring git
> > for a few of them. But the repositories are not nor will
> > ever be on a public server. There is no team development
> > on any of my projects, and I'm not planning any. 
> 
> Well, as outlined below I am suggesting git/svn not as means for
> concurrent/team development but for providing a canonical
> version-independent URL that can be tracked for each of the projects.
> 
> A symlink 'zita-rev1-latest.tar.bz2' could provide the former, but one
> won't be able to tell if there's any update without actually downloading
> it or checking the mtime with HTTP-HEAD.
> 
> >> watching http://www.kokkinizita.net/linuxaudio/downloads/index.html
> >> and upgrading apps there (which are not [yet] in common distributions)
> >> by hand is kind of tiresome, even more so since your Makefiles do not
> >> support 'make uninstall'.
> > 
> > Well... they are *source* packages. All it takes is download,
> > unpack, cd, sudo make install. 
> 
> That's 3 steps to much :) Besides: The issue with download is that the
> next version number is not predictable. One needs to use a web-browser.
> If it was a repository-checkout it'd be a one-time setup and just
> calling a single 'pull & build' script afterward.
> 
> With git it's also easy to keep more than one repo: fi. a private with
> all the small changes and a public where you only push out releases.
> 
> As for the 'sudo make install' - I'm quite reluctant to run that
> command. Usually a 'make' suffices for testing.
> ..and if I can't wait until a tool makes it into Debian I roll my own
> package for the meantime which provides for clean removal later on.
> 
> > The 'make remove' is a good idea,
> > I will be adding it to new releases.
> 
> The commonly used target (autotools) is "make uninstall"
> (not "make remove")
> 
> > OTOH, the installed size of
> > e.g. zita-rev1 (binary and *.png) is less than 100k, so little
> > is gained by removing it. 
> 
> The motivation is not about recovering disk-space about being able to
> keep the system clean.
> 
> Some of my earlier test|development machines|chroots quickly became
> messed up with different versions in /usr/lib /usr/local/lib and after a
> few weeks or month there was no hope but to re-install the thing.
> You may know this situation.
> 
> The overhead of rolling custom packages is small compared to
> re-installing or cleaning up by hand.
> 
> >> The nice thing is that your Makefiles are pretty clean. using dh_make,
> >> DESTDIR and quilt (change PREFIX to /usr)
> > 
> > you can define PREFIX on the make command line as well, there's
> > no need to modify the Makefile
> 
> aaw right.
> PREFIX=$HOME/usr make install # does not work but
> make PREFIX=$HOME/usr install # does
> 
> Thanks for the hint.
> 
> >> makes it easy to debianize them for local packaging; however if
> >> one could use git-buildpackage it would be even nicer.
> > 
> > Installer managed packages (taking care of dependencies etc.)
> > should be provided by the packagers of your distro, there's
> > no way I can do this. I don't even provide them for the distro
> > I use myself.
> > 
> 
> I agree programmers should not be concerned about packaging. I was just
> suggesting a few trivial changes that'll make live easier for PPL
> packaging (either for distros or for their own benefit).

The only thing I could wish for is a short announcement mail in case of
new versions. This way I'll update the packages in a more timely
fashion, otherwise some user of the package needs to tell me that
there's an update available, which can take weeks. The actual time for
me to update a package is usually 2 minutes.
I like short changelogs too.

Well, no big deal, just my little packagers wishlist.

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

Re: [LAD] Some new things to play with

[fons]

On Mon, Oct 11, 2010 at 03:47:43PM +0200, Robin Gareus wrote:

> Well, as outlined below I am suggesting git/svn not as means for
> concurrent/team development but for providing a canonical
> version-independent URL that can be tracked for each of the projects.

Updates are quite infrequent, and if there's anything really 
important or new they will be announced on LAD/LAU. It's not
like some projects which you could update almost daily.
 
> That's 3 steps to much :)

Are Linux users becoming that lazy ? :-)

> With git it's also easy to keep more than one repo: fi. a private with
> all the small changes and a public where you only push out releases.

I don't think that my provider (hosteurope) provides a git server.
 
> As for the 'sudo make install' - I'm quite reluctant to run that
> command.

I can't help to spot some contradition there. You would not trust
'sudo make install', even if you can verify very easily what it's
going to do (just a few lines in the Makefile). But you would trust
a single-command, almost automatic update ? This can do whatever it
wants with your system, even if going through a managed package,
and it's less easy to verify.

> Usually a 'make' suffices for testing.

For zita-rev1 for example it wouldn't - the application expects
some data in $PREFIX/share/zita-rev1/.

> The commonly used target (autotools) is "make uninstall"
> (not "make remove")

But I don't use autotools :-). It's easy to provide both.

> I agree programmers should not be concerned about packaging. I was just
> suggesting a few trivial changes that'll make live easier for PPL
> packaging (either for distros or for their own benefit).

If I can make life easier for packagers I will, that's why DESTDIR
was added for example. But I can't do anything specific for any
distro (or desktop).

Ciao, 

-- 
FA

There are three of them, and Alleline.

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

Re: [LAD] Some new things to play with

[Robin Gareus]

On 10/11/10 14:33, f...@kokkinizita.net wrote:
> On Mon, Oct 11, 2010 at 01:02:09PM +0200, Robin Gareus wrote:
> 
>> Are they also available from some repository (svn, git,..)?
> 
> No. Most projects here are in svn and I'm exploring git
> for a few of them. But the repositories are not nor will
> ever be on a public server. There is no team development
> on any of my projects, and I'm not planning any. 

Well, as outlined below I am suggesting git/svn not as means for
concurrent/team development but for providing a canonical
version-independent URL that can be tracked for each of the projects.

A symlink 'zita-rev1-latest.tar.bz2' could provide the former, but one
won't be able to tell if there's any update without actually downloading
it or checking the mtime with HTTP-HEAD.

>> watching http://www.kokkinizita.net/linuxaudio/downloads/index.html
>> and upgrading apps there (which are not [yet] in common distributions)
>> by hand is kind of tiresome, even more so since your Makefiles do not
>> support 'make uninstall'.
> 
> Well... they are *source* packages. All it takes is download,
> unpack, cd, sudo make install. 

That's 3 steps to much :) Besides: The issue with download is that the
next version number is not predictable. One needs to use a web-browser.
If it was a repository-checkout it'd be a one-time setup and just
calling a single 'pull & build' script afterward.

With git it's also easy to keep more than one repo: fi. a private with
all the small changes and a public where you only push out releases.

As for the 'sudo make install' - I'm quite reluctant to run that
command. Usually a 'make' suffices for testing.
..and if I can't wait until a tool makes it into Debian I roll my own
package for the meantime which provides for clean removal later on.

> The 'make remove' is a good idea,
> I will be adding it to new releases.

The commonly used target (autotools) is "make uninstall"
(not "make remove")

> OTOH, the installed size of
> e.g. zita-rev1 (binary and *.png) is less than 100k, so little
> is gained by removing it. 

The motivation is not about recovering disk-space about being able to
keep the system clean.

Some of my earlier test|development machines|chroots quickly became
messed up with different versions in /usr/lib /usr/local/lib and after a
few weeks or month there was no hope but to re-install the thing.
You may know this situation.

The overhead of rolling custom packages is small compared to
re-installing or cleaning up by hand.

>> The nice thing is that your Makefiles are pretty clean. using dh_make,
>> DESTDIR and quilt (change PREFIX to /usr)
> 
> you can define PREFIX on the make command line as well, there's
> no need to modify the Makefile

aaw right.
PREFIX=$HOME/usr make install # does not work but
make PREFIX=$HOME/usr install # does

Thanks for the hint.

>> makes it easy to debianize them for local packaging; however if
>> one could use git-buildpackage it would be even nicer.
> 
> Installer managed packages (taking care of dependencies etc.)
> should be provided by the packagers of your distro, there's
> no way I can do this. I don't even provide them for the distro
> I use myself.
> 

I agree programmers should not be concerned about packaging. I was just
suggesting a few trivial changes that'll make live easier for PPL
packaging (either for distros or for their own benefit).

Anyway congratulations on these effects. I've only tested the reverb  (I
don't [yet] have use for an autotuner) and it's brilliant.
I'm already looking forward to 'rack GUI'. Keep up the good work.

Cheers!
robin

PS.
Do you know or have any mirrors of kokkinizita.net? It'd be a pity if
all the great stuff on there would be lost in some accident.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Some new things to play with

[fons]

On Mon, Oct 11, 2010 at 01:02:09PM +0200, Robin Gareus wrote:

> Are they also available from some repository (svn, git,..)?

No. Most projects here are in svn and I'm exploring git
for a few of them. But the repositories are not nor will
ever be on a public server. There is no team development
on any of my projects, and I'm not planning any. 
 
> watching http://www.kokkinizita.net/linuxaudio/downloads/index.html
> and upgrading apps there (which are not [yet] in common distributions)
> by hand is kind of tiresome, even more so since your Makefiles do not
> support 'make uninstall'.

Well... they are *source* packages. All it takes is download,
unpack, cd, sudo make install. The 'make remove' is a good idea,
I will be adding it to new releases. OTOH, the installed size of
e.g. zita-rev1 (binary and *.png) is less than 100k, so little
is gained by removing it. 

> The nice thing is that your Makefiles are pretty clean. using dh_make,
> DESTDIR and quilt (change PREFIX to /usr)

you can define PREFIX on the make command line as well, there's
no need to modify the Makefile

> makes it easy to debianize them for local packaging; however if
> one could use git-buildpackage it would be even nicer.

Installer managed packages (taking care of dependencies etc.)
should be provided by the packagers of your distro, there's
no way I can do this. I don't even provide them for the distro
I use myself.


Ciao,

-- 
FA

There are three of them, and Alleline.

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

Re: [LAD] Some new things to play with

[alex stone]

On Mon, Oct 11, 2010 at 2:50 PM,   wrote:
> On Mon, Oct 11, 2010 at 03:31:58AM +0400, alex stone wrote:
>
>> On Mon, Oct 11, 2010 at 3:13 AM,   wrote:
>>
>> > Mmm. Using 8 reverbs for a single orchestral mix doesn't make
>> > any sense - unless you are doing something psychedelic (*) they
>> > all play in the same space. It's easy to share a reverb for any
>> > number of channels even if the dry/wet ratio is different for
>> > each.
>>
>> Using sample libs, which can vary in the amount of "presence" that is
>> recorded with instrument/sections, means multiple verb instances can
>> bring a little more consistency across the entire orchestra. My
>> example is of the 3 complete Strings libs i have, where 1 has more
>> presence in the base samples than the other 2. So i have to be careful
>> not to add too much to 1, and a little more to the other 2.
>> (And this is also true when blending "bright" string sections with
>> those that are duller. the duller samples tend to need a bit more
>> presence, and the bright samples survive with less, but conversely,
>> also need EQ'ing a little, to not stand out so much.)
>
> None of this means you need to use more than one reverb, and if
> the target is to have more consistency you definitely should use
> just one.
>
> Reverb is a linear operation.
>
> If F1, F2, F3 are linear operations (EQ, delay, gain), then
>
>  F1 (reverb (x1)) + F2 (reverb (x2)) + F3 (reverb (x3))
>
> is the same as
>
>  reverb (F1 (x1) + F2 (x2) + F3 (x3))
>
> which uses just one reverb.
>
>
> * Set the reverb to 100% 'wet' and connect the outputs to your
>  main mixing bus.
>
> * Send controlled amounts of each channel/group/section (after
>  fader) to the reverb input. You can even equalise or delay
>  these separately.
>
> Ciao,
>
> --
> FA
>
> There are three of them, and Alleline.
>
>

I'll try this again, Fons, thanks.

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

Re: [LAD] Some new things to play with

[Robin Gareus]

On 10/10/10 22:10, f...@kokkinizita.net wrote:

> More info at 

Hi Fons,

Are they also available from some repository (svn, git,..)?

watching http://www.kokkinizita.net/linuxaudio/downloads/index.html
and upgrading apps there (which are not [yet] in common distributions)
by hand is kind of tiresome, even more so since your Makefiles do not
support 'make uninstall'.

The nice thing is that your Makefiles are pretty clean. using dh_make,
DESTDIR and quilt (change PREFIX to /usr) makes it easy to debianize
them for local packaging; however if one could use git-buildpackage it
would be even nicer.

2c,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Some new things to play with

[fons]

On Mon, Oct 11, 2010 at 03:31:58AM +0400, alex stone wrote:

> On Mon, Oct 11, 2010 at 3:13 AM,   wrote:
>
> > Mmm. Using 8 reverbs for a single orchestral mix doesn't make
> > any sense - unless you are doing something psychedelic (*) they
> > all play in the same space. It's easy to share a reverb for any
> > number of channels even if the dry/wet ratio is different for
> > each.
>
> Using sample libs, which can vary in the amount of "presence" that is
> recorded with instrument/sections, means multiple verb instances can
> bring a little more consistency across the entire orchestra. My
> example is of the 3 complete Strings libs i have, where 1 has more
> presence in the base samples than the other 2. So i have to be careful
> not to add too much to 1, and a little more to the other 2.
> (And this is also true when blending "bright" string sections with
> those that are duller. the duller samples tend to need a bit more
> presence, and the bright samples survive with less, but conversely,
> also need EQ'ing a little, to not stand out so much.)

None of this means you need to use more than one reverb, and if
the target is to have more consistency you definitely should use
just one.

Reverb is a linear operation.

If F1, F2, F3 are linear operations (EQ, delay, gain), then

  F1 (reverb (x1)) + F2 (reverb (x2)) + F3 (reverb (x3)) 

is the same as

  reverb (F1 (x1) + F2 (x2) + F3 (x3))

which uses just one reverb.


* Set the reverb to 100% 'wet' and connect the outputs to your
  main mixing bus.

* Send controlled amounts of each channel/group/section (after 
  fader) to the reverb input. You can even equalise or delay
  these separately.

Ciao,

-- 
FA

There are three of them, and Alleline.

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

Re: [LAD] Some new things to play with

[fons]

On Sun, Oct 10, 2010 at 07:31:08PM -0400, Jeremy wrote:

> > processors that will eventually be released as plugins in
> > a 'rack' type of host. The GUIs and some of the internals are
> > already designed to fit into that format. When that happens,
> > the rack will have 'total recall' (session and snapshots),
> > and each plugin type will have presets (per user).
> >
> 
> Does this mean you are going to release specifications for a new plugin
> format?  Or will this be specific to your code?

Yes, this will be a new plugin API, support libraries for both
plugins and hosts will be provided, but I'm not going to actively
promote it as a replacement for anything existing. 

It's not designed to be 'simple' - plugins and hosts *must* support 
a minimal functionality much wider than LADSPA or LV2. For example
plugins must have a dedicated GUI, there is no such thing as a host
constructing a GUI from e.g. control port descriptors - these are
not even visible to a host. If a plugin supports multichannel use,
this must be provided explicitly - the host can not just replicate
the DSP code. There are many other differences, and some of them
have far reaching consequences.

This may well discourage 'novice' programmers, but that is to some
extent intentional. I want this format to be used only for plugins
that conform to some minimal quality standards. So it's not meant
to provide an easy way to create a wrapper around some DSP code you
don't even have to understand.

I'm creating apps such as REV1, AT1 and some others as test cases.
The specs are being reviewed and modified regularly as a result.

Ciao,

-- 
FA

There are three of them, and Alleline.

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