[Jamin] Feature Request JAMin

[Florian Kraxberger]

Hello Ladies and Gentlemen!

First of all I have to ask: Is JAMin in active development? The latest
entry in the news section on the JAMin homepage (jamin.sourceforge.net)
dates back in 2005.
I'm asking because I have an idea to submit, as I am not a programmer
but only a user of your great program.

Is it possible to make JAMin capable of multi channel output? I would
like to use seperate outputs for seperate crossover bands, for example
if you take 6 outputs they would be used as following: high frequency
band left and right, mid frequency band left and right and low frequency
band left and right. This feature would be very useful for live sound
applications.

If this feature already exists, I must have missed it, please tell me
where I can enable it.
If this feature is in development, thank you very much for taking your
time to make this awesome program even better!
If a discussion on this topic has already come to a conclusion, I am
sorry that I picked up this topic again, but as I am new to this mailing
list, I couldn't have known it anyway.

If you have questions about my feature request, pleast don't hesitate to
ask. I will respond as soon as possible.
I am looking forward to recieving your answer!

With best regards,
Florian Kraxberger

Email: ***@kraxberger.org
Current Linux Distribution: Ubuntu 12.10 64bit
Current version of JACK: 0.3.9 (from Ubuntu repos)
Current version of JAMin: 0.97.14 (also from Ubuntu repos)

[Patrick Shirkey]

Post by Florian Kraxberger
Hello Ladies and Gentlemen!
First of all I have to ask: Is JAMin in active development? The latest
entry in the news section on the JAMin homepage (jamin.sourceforge.net)
dates back in 2005.

The project is still alive but no one has had any time or motivation to do
anything recently.

Post by Florian Kraxberger
I'm asking because I have an idea to submit, as I am not a programmer
but only a user of your great program.
Is it possible to make JAMin capable of multi channel output?

It is technically possible but that functionality has not been written yet.

Post by Florian Kraxberger
I would
like to use seperate outputs for seperate crossover bands, for example
if you take 6 outputs they would be used as following: high frequency
band left and right, mid frequency band left and right and low frequency
band left and right. This feature would be very useful for live sound
applications.

Do you want access to the signals pre or post compression?

Post by Florian Kraxberger
If this feature already exists, I must have missed it, please tell me
where I can enable it.

It doesn't exist yet.

Post by Florian Kraxberger
If this feature is in development, thank you very much for taking your
time to make this awesome program even better!

Hasn't been discussed IIRC.

Post by Florian Kraxberger
If a discussion on this topic has already come to a conclusion, I am
sorry that I picked up this topic again, but as I am new to this mailing
list, I couldn't have known it anyway.
If you have questions about my feature request, pleast don't hesitate to
ask. I will respond as soon as possible.
I am looking forward to recieving your answer!
With best regards,
Florian Kraxberger
Current Linux Distribution: Ubuntu 12.10 64bit
Current version of JACK: 0.3.9 (from Ubuntu repos)
Current version of JAMin: 0.97.14 (also from Ubuntu repos)
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel

--
Patrick Shirkey
Boost Hardware Ltd

[John Rigg]

Post by Florian Kraxberger
Is it possible to make JAMin capable of multi channel output? I would
like to use seperate outputs for seperate crossover bands, for example
if you take 6 outputs they would be used as following: high frequency
band left and right, mid frequency band left and right and low frequency
band left and right. This feature would be very useful for live sound
applications.

Personally I would hesitate to use JAMin for live sound as it has quite
a lot of latency - certainly enough to cause problems for performers if
used on monitor sends, and possibly also enough to cause phase problems
between direct sound from the stage and the PA speakers.

John

[Patrick Shirkey]

Post by John Rigg

Post by Florian Kraxberger
Is it possible to make JAMin capable of multi channel output? I would
like to use seperate outputs for seperate crossover bands, for example
if you take 6 outputs they would be used as following: high frequency
band left and right, mid frequency band left and right and low frequency
band left and right. This feature would be very useful for live sound
applications.

Personally I would hesitate to use JAMin for live sound as it has quite
a lot of latency - certainly enough to cause problems for performers if
used on monitor sends, and possibly also enough to cause phase problems
between direct sound from the stage and the PA speakers.

I guess the question is what kind of live performance use is the intention?

It's also possible to use Jamin as an fx box instead of a mastering tool...

IIRC internal latency is about as good as it gets but maybe there are
improvements or tradeoffs that could be added for live use?



--
Patrick Shirkey
Boost Hardware Ltd

[John Rigg]

Post by Patrick Shirkey

Post by John Rigg
Personally I would hesitate to use JAMin for live sound as it has quite
a lot of latency - certainly enough to cause problems for performers if
used on monitor sends, and possibly also enough to cause phase problems
between direct sound from the stage and the PA speakers.

I guess the question is what kind of live performance use is the intention?
It's also possible to use Jamin as an fx box instead of a mastering tool...
IIRC internal latency is about as good as it gets but maybe there are
improvements or tradeoffs that could be added for live use?

I haven't measured the latency, but operating the bypass button does
make the timing jump by enough to make me think it could be a problem for
live musicians. Anything much over 10ms total can cause timing problems
for some musicians. That's about the time it takes sound to travel 10 feet,
which might appear insignificant, but I do know musicians for whom this
could be an issue. Increase that to 20ms total and it's potentially a
problem for just about any musician trying to play in time with others on
a small stage. That much delay between back line sound and PA speakers
could also be quite noticeable.

Without measurements this is all conjecture of course. If I get time I'll
try to do some tests.

There's nothing unreasonable about the OP's feature request BTW. It could
be useful in situations where latency isn't a problem, like playing
pre-recorded music, but that isn't what I usually think of as live
sound ;-)

John

[David Nielson]

Post by John Rigg
Without measurements this is all conjecture of course. If I get time I'll
try to do some tests.

Jamin adds 1024 samples of latency to a signal on top of whatever
latency is added by your system. It's really not a good choice for a
crossover in a performance system with live performers. It would be
great for DJing.

A few years ago, I did a digital crossover setup using Ardour and a
plugin called EQ10T, which is sadly no longer maintained and impossible
to compile in a modern operating system.

You can probably get excellent results with Calf's LV2 filter plugin,
which looks like an IIR filter--meaning reduced latency. Alas, I no
longer have my sound system, so I can't test this to see how it does in
reality.

David

[Jan Depner]

Post by David Nielson

Post by John Rigg
Without measurements this is all conjecture of course. If I get time I'll
try to do some tests.

Jamin adds 1024 samples of latency to a signal on top of whatever
latency is added by your system. It's really not a good choice for a
crossover in a performance system with live performers. It would be
great for DJing.
A few years ago, I did a digital crossover setup using Ardour and a
plugin called EQ10T, which is sadly no longer maintained and impossible
to compile in a modern operating system.

Where can I get a copy of EQ10T? I Googled it and got NADA. I'd like
to take a look at getting it to compile. I really don't think JAMin is
the right tool for the job here. The latency is a killer. It was
designed for a specific task (mastering) and it really isn't designed
for anything else (which is why it isn't being constantly tweaked).

Post by David Nielson
You can probably get excellent results with Calf's LV2 filter plugin,
which looks like an IIR filter--meaning reduced latency. Alas, I no
longer have my sound system, so I can't test this to see how it does in
reality.
David
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel

[Patrick Shirkey]

Post by Jan Depner

Post by David Nielson

Post by John Rigg
Without measurements this is all conjecture of course. If I get time

I'll

Post by John Rigg
try to do some tests.

Jamin adds 1024 samples of latency to a signal on top of whatever
latency is added by your system. It's really not a good choice for a
crossover in a performance system with live performers. It would be
great for DJing.
A few years ago, I did a digital crossover setup using Ardour and a
plugin called EQ10T, which is sadly no longer maintained and impossible
to compile in a modern operating system.

Where can I get a copy of EQ10T? I Googled it and got NADA. I'd like
to take a look at getting it to compile. I really don't think JAMin is
the right tool for the job here. The latency is a killer. It was
designed for a specific task (mastering) and it really isn't designed
for anything else (which is why it isn't being constantly tweaked).

It was also originally built for machines that were a lot less powerful
than we have today.

There are a bunch of additional features that Jamin could have:

1: Simplified UI for preset configurations (partially built)
2: Daemon mode
3: Control UI for Daemon mode
3: Pre/Post compressors aux/send
4: Updated interface using gtk3+clutter for 3d visualisations
5: Modernised UI design for touch interfaces
6: A choice of compressors/limiters
7: LV2 plugin option


etc...



--
Patrick Shirkey
Boost Hardware Ltd

[Michiel Broek]

Post by Patrick Shirkey
It was also originally built for machines that were a lot less powerful
than we have today.
1: Simplified UI for preset configurations (partially built)
2: Daemon mode
3: Control UI for Daemon mode
3: Pre/Post compressors aux/send
4: Updated interface using gtk3+clutter for 3d visualisations
5: Modernised UI design for touch interfaces
6: A choice of compressors/limiters
7: LV2 plugin option
etc...

Jamin could use a facelift, but just minor things. Jamin is not suitable
for live sound, for live sound you only need limiters on the output
stages, no compressors at all. Personally I would invest in a hardware
unit instead of spending the same (or maybe more) money on a
PC/soundcards solution.

But if someone would decide to go ahead building a solution for live
sound, then I would like to see that happen in a fork of Jamin instead
of trying to build all in one application.

just my 2 cts,

Michiel Broek.

Post by Patrick Shirkey
--
Patrick Shirkey
Boost Hardware Ltd
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel

[Thomas Vecchione]

Post by Michiel Broek
Jamin could use a facelift, but just minor things. Jamin is not suitable
for live sound, for live sound you only need limiters on the output
stages, no compressors at all. Personally I would invest in a hardware
unit instead of spending the same (or maybe more) money on a
PC/soundcards solution.

Actually compressors on outputs aren't uncommon in live sound. For
instance in one of the venues I am currently running I have a multiband
compressor on the output, as otherwise when pushed hard the tweeters in the
drivers get very harsh very quick, where a multiband compressor helps to
tame this significantly, something I just did about a month ago and has
worked splendidly thus far. A simple 2:1 compression on the outputs with a
fairly decently high threshold will help levels from spiraling out of
control to quickly, etc. without killing all dynamics like a limiter would.

You don't typically need to use makeup gain on the output compressors true,
but even that is debateable. But compressors certainly get used as well on
outputs of live sound, and of course this isn't even touching the input
side as I don't think you were debating that.

Seablade

[Patrick Shirkey]

Post by Michiel Broek

Post by Patrick Shirkey
It was also originally built for machines that were a lot less powerful
than we have today.
1: Simplified UI for preset configurations (partially built)
2: Daemon mode
3: Control UI for Daemon mode
3: Pre/Post compressors aux/send
4: Updated interface using gtk3+clutter for 3d visualisations
5: Modernised UI design for touch interfaces
6: A choice of compressors/limiters
7: LV2 plugin option
etc...

Jamin could use a facelift, but just minor things. Jamin is not suitable
for live sound, for live sound you only need limiters on the output
stages, no compressors at all.

This could be handled with a simple toggle to bypass the compressors?

Post by Michiel Broek
Personally I would invest in a hardware
unit instead of spending the same (or maybe more) money on a
PC/soundcards solution.

And if you already had a PC that you wanted to use for live sound would
you not want to try out a free open source Linux Audio solution before
spending more money on a hardware solution?

In addition would you not be interested in a hardware solution running
jamin ootb that could be built by anyone with the funds/motivation to do
so?

Post by Michiel Broek
But if someone would decide to go ahead building a solution for live
sound, then I would like to see that happen in a fork of Jamin instead
of trying to build all in one application.

I don't understand why you would request a fork. Jamin hasn't changed for
several years so making some additions is hardly a big deal. If you wanted
to continue using the older interface there could even be a "classic"
interface for people with that specific need.

Multiple interfaces for multiple uses. Jamin as a mastering tool for live
and post prod. Makes sense to me to have it all in one place. A flexible
and highly customisable solution for audio quality. The sound engineers
best friend on or off stage...

Also I'm not sure about this supposed 1024 period limit. I don't recall
that being baked in. Has anyone tested with a jack period size lower than
1024?

i.e.

jackd - a alsa -p 512
jackd - a alsa -p 256
jackd - a alsa -p 128
jackd - a alsa -p 64
jackd - a alsa -p 32
jackd - a alsa -p 16
jackd - a alsa -p 8

etc...

--
Patrick Shirkey
Boost Hardware Ltd

[David Nielson]

Last night I used Calf's Jack Rack app with two Filter instances and
found them to be quite suitable for a crossover. Caveat, I don't have
any actual 2-way or higher order speakers to play with; but the options
are as good as what EQ10T offered, and the maintenance is 100x better.

Post by Patrick Shirkey
Also I'm not sure about this supposed 1024 period limit. I don't recall
that being baked in. Has anyone tested with a jack period size lower than
1024?

No, it's not that it requires that large of a period size; is that Jamin
uses FIR filtering, and the filter length is fixed at 1024 samples. You
should think of Jamin as all the features you want, plus a 1024-sample
delay.

David

[Patrick Shirkey]

Post by David Nielson
Last night I used Calf's Jack Rack app with two Filter instances and
found them to be quite suitable for a crossover. Caveat, I don't have
any actual 2-way or higher order speakers to play with; but the options
are as good as what EQ10T offered, and the maintenance is 100x better.

Post by Patrick Shirkey
Also I'm not sure about this supposed 1024 period limit. I don't recall
that being baked in. Has anyone tested with a jack period size lower than
1024?

No, it's not that it requires that large of a period size; is that Jamin
uses FIR filtering, and the filter length is fixed at 1024 samples. You
should think of Jamin as all the features you want, plus a 1024-sample
delay.

Jamin supports both FIR or iIR.

According to this page FIR filters can be run at a minimum time of 1.25ms
in 3 way mode with a total delay of 3 -5 ms for latency compensation.

http://forums.prosoundweb.com/index.php?topic=2045.0

We do have 1024 EQ bands for the hdeq, but that number could be adjustable
too. IIRC, the only reason 1024 bands is hardcoded is that no one saw a
need for any other number in the hdeq at the time. Not because it is the
only way to do things. If there is a need for smaller EQ band sets we can
add that functionality.

FYI, we had a very small pool of mastering engineers providing feedback at
the time of the first phase of development.




--
Patrick Shirkey
Boost Hardware Ltd

[Michiel Broek]

Post by Patrick Shirkey

Post by Michiel Broek

Post by Patrick Shirkey
It was also originally built for machines that were a lot less powerful
than we have today.
1: Simplified UI for preset configurations (partially built)
2: Daemon mode
3: Control UI for Daemon mode
3: Pre/Post compressors aux/send
4: Updated interface using gtk3+clutter for 3d visualisations
5: Modernised UI design for touch interfaces
6: A choice of compressors/limiters
7: LV2 plugin option
etc...

Jamin could use a facelift, but just minor things. Jamin is not suitable
for live sound, for live sound you only need limiters on the output
stages, no compressors at all.

This could be handled with a simple toggle to bypass the compressors?

That's true.

Post by Patrick Shirkey

Post by Michiel Broek
Personally I would invest in a hardware
unit instead of spending the same (or maybe more) money on a
PC/soundcards solution.

And if you already had a PC that you wanted to use for live sound would
you not want to try out a free open source Linux Audio solution before
spending more money on a hardware solution?
In addition would you not be interested in a hardware solution running
jamin ootb that could be built by anyone with the funds/motivation to do
so?

I see it like this. A unit for live sound is adjusted once for the
combination of speaker units and amplifiers. Then only minor teaks may
be needed for certain halls, but in most cases it's not necessary. If
all is adjusted, lock the unit and bury the password. There is a reason
why these DSP's have so few knobs.

Mastering is different, each song is different and even the same song
can be made different just by tuning Jamin. Jamin does a good job and
works well combined with Ardour.

I see it as two whole different things even if a lot of processing is
the same.

Post by Patrick Shirkey

Post by Michiel Broek
But if someone would decide to go ahead building a solution for live
sound, then I would like to see that happen in a fork of Jamin instead
of trying to build all in one application.

I don't understand why you would request a fork. Jamin hasn't changed for
several years so making some additions is hardly a big deal. If you wanted
to continue using the older interface there could even be a "classic"
interface for people with that specific need.
Multiple interfaces for multiple uses. Jamin as a mastering tool for live
and post prod. Makes sense to me to have it all in one place. A flexible
and highly customisable solution for audio quality. The sound engineers
best friend on or off stage...

I guess if I would design a software DSP based on Jamin technology, I
still would like it to be so that no one passing by that computer can
change any setting. It's just needed once and is mostly stacked away in
the amp racks too, so it's not in range of the FOH mixer.

Post by Patrick Shirkey
Also I'm not sure about this supposed 1024 period limit. I don't recall
that being baked in. Has anyone tested with a jack period size lower than
1024?
i.e.
jackd - a alsa -p 512
jackd - a alsa -p 256
jackd - a alsa -p 128
jackd - a alsa -p 64
jackd - a alsa -p 32
jackd - a alsa -p 16
jackd - a alsa -p 8

I don't think it's fixed. It must be from slow hardware days where
everyone advised to use 1024 to prevent xruns.
But that's not the largest delay in Jamin, it's the brick limiter that
has the long delay. But if you shorten the delay the bass frequencies
will distort, I even use a longer delay that the default. No problem for
studio work, but unacceptable for live.
Turning the limiter off leave you only with the 1024 period delay. I
think using 96 kb audio the delay is acceptable. Real hardware DSP's
have a little delay too, it are also digital units.

gtx, Michiel.

[Patrick Shirkey]

Post by Michiel Broek

Post by Patrick Shirkey

Post by Michiel Broek

Post by Patrick Shirkey
It was also originally built for machines that were a lot less powerful
than we have today.
1: Simplified UI for preset configurations (partially built)
2: Daemon mode
3: Control UI for Daemon mode
3: Pre/Post compressors aux/send
4: Updated interface using gtk3+clutter for 3d visualisations
5: Modernised UI design for touch interfaces
6: A choice of compressors/limiters
7: LV2 plugin option
etc...

Jamin could use a facelift, but just minor things. Jamin is not suitable
for live sound, for live sound you only need limiters on the output
stages, no compressors at all.

This could be handled with a simple toggle to bypass the compressors?

That's true.

Post by Patrick Shirkey

Post by Michiel Broek
Personally I would invest in a hardware
unit instead of spending the same (or maybe more) money on a
PC/soundcards solution.

And if you already had a PC that you wanted to use for live sound would
you not want to try out a free open source Linux Audio solution before
spending more money on a hardware solution?
In addition would you not be interested in a hardware solution running
jamin ootb that could be built by anyone with the funds/motivation to do
so?

I see it like this. A unit for live sound is adjusted once for the
combination of speaker units and amplifiers. Then only minor teaks may
be needed for certain halls, but in most cases it's not necessary. If
all is adjusted, lock the unit and bury the password. There is a reason
why these DSP's have so few knobs.
Mastering is different, each song is different and even the same song
can be made different just by tuning Jamin. Jamin does a good job and
works well combined with Ardour.
I see it as two whole different things even if a lot of processing is
the same.

Post by Patrick Shirkey

Post by Michiel Broek
But if someone would decide to go ahead building a solution for live
sound, then I would like to see that happen in a fork of Jamin instead
of trying to build all in one application.

I don't understand why you would request a fork. Jamin hasn't changed for
several years so making some additions is hardly a big deal. If you wanted
to continue using the older interface there could even be a "classic"
interface for people with that specific need.
Multiple interfaces for multiple uses. Jamin as a mastering tool for live
and post prod. Makes sense to me to have it all in one place. A flexible
and highly customisable solution for audio quality. The sound engineers
best friend on or off stage...

I guess if I would design a software DSP based on Jamin technology, I
still would like it to be so that no one passing by that computer can
change any setting. It's just needed once and is mostly stacked away in
the amp racks too, so it's not in range of the FOH mixer.

In order to achieve something like this with jamin we need a daemon mode.
There is one thing in the way of that at the moment. It also affects the
"presets" ui mode (-g). Basically the hdeq requires to be realized at
least once before everything will work as expected. The hack is to
realize the main window then hide it but in daemon mode we don't want to
realize any windows.

Jan do you have any tips on how to bypass "realizing" the hdeq. I notice
we have the heq_pixmap for offscreen drawable so it looks like we are
pretty close already.

Post by Michiel Broek

Post by Patrick Shirkey
Also I'm not sure about this supposed 1024 period limit. I don't recall
that being baked in. Has anyone tested with a jack period size lower than
1024?
i.e.
jackd - a alsa -p 512
jackd - a alsa -p 256
jackd - a alsa -p 128
jackd - a alsa -p 64
jackd - a alsa -p 32
jackd - a alsa -p 16
jackd - a alsa -p 8

I don't think it's fixed. It must be from slow hardware days where
everyone advised to use 1024 to prevent xruns.
But that's not the largest delay in Jamin, it's the brick limiter that
has the long delay. But if you shorten the delay the bass frequencies
will distort, I even use a longer delay that the default. No problem for
studio work, but unacceptable for live.
Turning the limiter off leave you only with the 1024 period delay. I
think using 96 kb audio the delay is acceptable. Real hardware DSP's
have a little delay too, it are also digital units.
gtx, Michiel.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel

--
Patrick Shirkey
Boost Hardware Ltd

[Michiel Broek]

Post by Patrick Shirkey

Post by Michiel Broek
I see it like this. A unit for live sound is adjusted once for the
combination of speaker units and amplifiers. Then only minor teaks may
be needed for certain halls, but in most cases it's not necessary. If
all is adjusted, lock the unit and bury the password. There is a reason
why these DSP's have so few knobs.
Mastering is different, each song is different and even the same song
can be made different just by tuning Jamin. Jamin does a good job and
works well combined with Ardour.
I see it as two whole different things even if a lot of processing is
the same.

Post by Patrick Shirkey

Post by Michiel Broek
But if someone would decide to go ahead building a solution for live
sound, then I would like to see that happen in a fork of Jamin instead
of trying to build all in one application.

I don't understand why you would request a fork. Jamin hasn't changed for
several years so making some additions is hardly a big deal. If you wanted
to continue using the older interface there could even be a "classic"
interface for people with that specific need.
Multiple interfaces for multiple uses. Jamin as a mastering tool for live
and post prod. Makes sense to me to have it all in one place. A flexible
and highly customisable solution for audio quality. The sound engineers
best friend on or off stage...

I guess if I would design a software DSP based on Jamin technology, I
still would like it to be so that no one passing by that computer can
change any setting. It's just needed once and is mostly stacked away in
the amp racks too, so it's not in range of the FOH mixer.

In order to achieve something like this with jamin we need a daemon mode.
There is one thing in the way of that at the moment. It also affects the
"presets" ui mode (-g). Basically the hdeq requires to be realized at
least once before everything will work as expected. The hack is to
realize the main window then hide it but in daemon mode we don't want to
realize any windows.
Jan do you have any tips on how to bypass "realizing" the hdeq. I notice
we have the heq_pixmap for offscreen drawable so it looks like we are
pretty close already.

Based on these ideas I would suggest to split it in two parts. The
daemon that does the processing and listens on a network socket for a
controlling app.
Build the controller app and let in communicate over the network. Then
you have the full freedom to install everything on one machine, or run
headless, or run remote controlled. For local use, use named sockets only.

gtx, Michiel.

[Patrick Shirkey]

Post by Michiel Broek

Post by Patrick Shirkey

Post by Michiel Broek
I see it like this. A unit for live sound is adjusted once for the
combination of speaker units and amplifiers. Then only minor teaks may
be needed for certain halls, but in most cases it's not necessary. If
all is adjusted, lock the unit and bury the password. There is a reason
why these DSP's have so few knobs.
Mastering is different, each song is different and even the same song
can be made different just by tuning Jamin. Jamin does a good job and
works well combined with Ardour.
I see it as two whole different things even if a lot of processing is
the same.

Post by Patrick Shirkey

Post by Michiel Broek
But if someone would decide to go ahead building a solution for live
sound, then I would like to see that happen in a fork of Jamin instead
of trying to build all in one application.

I don't understand why you would request a fork. Jamin hasn't changed for
several years so making some additions is hardly a big deal. If you wanted
to continue using the older interface there could even be a "classic"
interface for people with that specific need.
Multiple interfaces for multiple uses. Jamin as a mastering tool for live
and post prod. Makes sense to me to have it all in one place. A flexible
and highly customisable solution for audio quality. The sound engineers
best friend on or off stage...

I guess if I would design a software DSP based on Jamin technology, I
still would like it to be so that no one passing by that computer can
change any setting. It's just needed once and is mostly stacked away in
the amp racks too, so it's not in range of the FOH mixer.

In order to achieve something like this with jamin we need a daemon mode.
There is one thing in the way of that at the moment. It also affects the
"presets" ui mode (-g). Basically the hdeq requires to be realized at
least once before everything will work as expected. The hack is to
realize the main window then hide it but in daemon mode we don't want to
realize any windows.
Jan do you have any tips on how to bypass "realizing" the hdeq. I notice
we have the heq_pixmap for offscreen drawable so it looks like we are
pretty close already.

Based on these ideas I would suggest to split it in two parts. The
daemon that does the processing and listens on a network socket for a
controlling app.
Build the controller app and let in communicate over the network. Then
you have the full freedom to install everything on one machine, or run
headless, or run remote controlled. For local use, use named sockets only.

We already have osc support so we might not need a new socket. I think we
can add a flag for remote controlling the daemon via the existing
interface.

I'm not completely across OSC though so if anyone has a suggestion for the
best way to handle it functionally please let me know.

FYI, I have managed to get past the issue of "realizing" the hdeq widget.
Turns out that the update_meters() function was the culprit.

I'm looking at the Daemon mode now and then I will make an update to cvs
for others to test out...




--
Patrick Shirkey
Boost Hardware Ltd

[Udo van den Heuvel]

Post by Patrick Shirkey
We already have osc support so we might not need a new socket. I think we
can add a flag for remote controlling the daemon via the existing
interface.

Small question:
Where on the web is the howto to enable OSC in Jamin?

Kind regards,
Udo

[Michiel Broek]

Post by Patrick Shirkey

Post by Michiel Broek

Post by Patrick Shirkey

Post by Michiel Broek
I see it like this. A unit for live sound is adjusted once for the
combination of speaker units and amplifiers. Then only minor teaks may
be needed for certain halls, but in most cases it's not necessary. If
all is adjusted, lock the unit and bury the password. There is a reason
why these DSP's have so few knobs.
Mastering is different, each song is different and even the same song
can be made different just by tuning Jamin. Jamin does a good job and
works well combined with Ardour.
I see it as two whole different things even if a lot of processing is
the same.

Post by Patrick Shirkey

Post by Michiel Broek
But if someone would decide to go ahead building a solution for live
sound, then I would like to see that happen in a fork of Jamin instead
of trying to build all in one application.

I don't understand why you would request a fork. Jamin hasn't changed for
several years so making some additions is hardly a big deal. If you wanted
to continue using the older interface there could even be a "classic"
interface for people with that specific need.
Multiple interfaces for multiple uses. Jamin as a mastering tool for live
and post prod. Makes sense to me to have it all in one place. A flexible
and highly customisable solution for audio quality. The sound engineers
best friend on or off stage...

I guess if I would design a software DSP based on Jamin technology, I
still would like it to be so that no one passing by that computer can
change any setting. It's just needed once and is mostly stacked away in
the amp racks too, so it's not in range of the FOH mixer.

In order to achieve something like this with jamin we need a daemon mode.
There is one thing in the way of that at the moment. It also affects the
"presets" ui mode (-g). Basically the hdeq requires to be realized at
least once before everything will work as expected. The hack is to
realize the main window then hide it but in daemon mode we don't want to
realize any windows.
Jan do you have any tips on how to bypass "realizing" the hdeq. I notice
we have the heq_pixmap for offscreen drawable so it looks like we are
pretty close already.

Based on these ideas I would suggest to split it in two parts. The
daemon that does the processing and listens on a network socket for a
controlling app.
Build the controller app and let in communicate over the network. Then
you have the full freedom to install everything on one machine, or run
headless, or run remote controlled. For local use, use named sockets only.

We already have osc support so we might not need a new socket. I think we
can add a flag for remote controlling the daemon via the existing
interface.
I'm not completely across OSC though so if anyone has a suggestion for the
best way to handle it functionally please let me know.
FYI, I have managed to get past the issue of "realizing" the hdeq widget.
Turns out that the update_meters() function was the culprit.
I'm looking at the Daemon mode now and then I will make an update to cvs
for others to test out...

Patrick, for some ideas about live units,
http://www.dbxpro.com/en-US/product_families/driverack
The building blocks in Jamin are there, but I think you need a lot of
configuration options to get to one of these dbx units.


gtx, Michiel.

[Patrick Shirkey]

Post by Michiel Broek

Post by Patrick Shirkey

Post by Michiel Broek

Post by Patrick Shirkey

Post by Michiel Broek
I see it like this. A unit for live sound is adjusted once for the
combination of speaker units and amplifiers. Then only minor teaks may
be needed for certain halls, but in most cases it's not necessary.
If
all is adjusted, lock the unit and bury the password. There is a reason
why these DSP's have so few knobs.
Mastering is different, each song is different and even the same song
can be made different just by tuning Jamin. Jamin does a good job and
works well combined with Ardour.
I see it as two whole different things even if a lot of processing is
the same.

Post by Patrick Shirkey

Post by Michiel Broek
But if someone would decide to go ahead building a solution for live
sound, then I would like to see that happen in a fork of Jamin instead
of trying to build all in one application.

I don't understand why you would request a fork. Jamin hasn't
changed
for
several years so making some additions is hardly a big deal. If you wanted
to continue using the older interface there could even be a "classic"
interface for people with that specific need.
Multiple interfaces for multiple uses. Jamin as a mastering tool for live
and post prod. Makes sense to me to have it all in one place. A flexible
and highly customisable solution for audio quality. The sound engineers
best friend on or off stage...

I guess if I would design a software DSP based on Jamin technology, I
still would like it to be so that no one passing by that computer can
change any setting. It's just needed once and is mostly stacked away in
the amp racks too, so it's not in range of the FOH mixer.

In order to achieve something like this with jamin we need a daemon mode.
There is one thing in the way of that at the moment. It also affects the
"presets" ui mode (-g). Basically the hdeq requires to be realized at
least once before everything will work as expected. The hack is to
realize the main window then hide it but in daemon mode we don't want to
realize any windows.
Jan do you have any tips on how to bypass "realizing" the hdeq. I notice
we have the heq_pixmap for offscreen drawable so it looks like we are
pretty close already.

Based on these ideas I would suggest to split it in two parts. The
daemon that does the processing and listens on a network socket for a
controlling app.
Build the controller app and let in communicate over the network. Then
you have the full freedom to install everything on one machine, or run
headless, or run remote controlled. For local use, use named sockets only.

We already have osc support so we might not need a new socket. I think we
can add a flag for remote controlling the daemon via the existing
interface.
I'm not completely across OSC though so if anyone has a suggestion for the
best way to handle it functionally please let me know.
FYI, I have managed to get past the issue of "realizing" the hdeq widget.
Turns out that the update_meters() function was the culprit.
I'm looking at the Daemon mode now and then I will make an update to cvs
for others to test out...

Patrick, for some ideas about live units,
http://www.dbxpro.com/en-US/product_families/driverack
The building blocks in Jamin are there, but I think you need a lot of
configuration options to get to one of these dbx units.

What would you say we are missing at the moment that is the most obvious
feature to include in a live processing unit?





--
Patrick Shirkey
Boost Hardware Ltd

[David Nielson]

Post by Patrick Shirkey
What would you say we are missing at the moment that is the most obvious
feature to include in a live processing unit?

Separate outputs for each frequency band are the only thing *really*
missing before Jamin can replace most of the DBX Driverack units in use.

More channels will be necessary for other use cases, such as LCR,
Quadro, 5.1, Ambisonic, etc.

More bands would be awesome. I can use 8. (Yes, really!)

Other than that, Jamin can do everything I would have needed for my old
PA system.

David

[Patrick Shirkey]

Post by David Nielson

Post by Patrick Shirkey
What would you say we are missing at the moment that is the most obvious
feature to include in a live processing unit?

Separate outputs for each frequency band are the only thing *really*
missing before Jamin can replace most of the DBX Driverack units in use.

Do you mean 3 stereo outputs for the pre/post compressors or do you mean
an individual output for each band in the eq?

We could do 32 bands without much overhead as we already have support for
that in the internals. 1024 outputs is going to be tricky because of the
physical port limitations that a standard jack instance allows. 256 by
default.

Post by David Nielson
More channels will be necessary for other use cases, such as LCR,
Quadro, 5.1, Ambisonic, etc.

This would be very useful for many different cases. Do you have any
suggestions for how to manage the output signals in the UI/backend?

I'm thinking of a runtime flag that enables the additional jack outputs
for the advanced user. It could also be a toggle switch/button in the
interface. We would need to create some kind of volume control interface
too for the individual outputs.

It would probably be god to provide a flexible output interface so we can
switch between different output configurations easily.

How would we handle the compressors/limiters for each individual band?

Post by David Nielson
More bands would be awesome. I can use 8. (Yes, really!)
Other than that, Jamin can do everything I would have needed for my old
PA system.

--
Patrick Shirkey
Boost Hardware Ltd

[David Nielson]

Post by Patrick Shirkey

Post by David Nielson

Post by Patrick Shirkey
What would you say we are missing at the moment that is the most obvious
feature to include in a live processing unit?

Separate outputs for each frequency band are the only thing *really*
missing before Jamin can replace most of the DBX Driverack units in use.

Do you mean 3 stereo outputs for the pre/post compressors or do you mean
an individual output for each band in the eq?

Yes, I mean the pre/post compressors; so with a current Jamin
configuration, you'd have 6 outputs: L/R high, L/R mid, L/R low.

Post by Patrick Shirkey
We could do 32 bands without much overhead as we already have support for
that in the internals. 1024 outputs is going to be tricky because of the
physical port limitations that a standard jack instance allows. 256 by
default.

There may be a use case for splitting things into 32 or 1024 separate
JACK outputs per EQ band, but I can't think of one.

Post by Patrick Shirkey
This would be very useful for many different cases. Do you have any
suggestions for how to manage the output signals in the UI/backend?

IMO, the user should just be able to apply the same settings to a larger
number of channels. If you need different settings for your rear
speakers than your front speakers, you should use a separate instance.

The compressor sections have stereo width adjusters. For channels = 3,
you might set up stereo width adjustments that assume an LCR
configuration. For more than 3 channels, IMO, Jamin should not make any
width or panning adjustments at all.

Post by Patrick Shirkey
I'm thinking of a runtime flag that enables the additional jack outputs
for the advanced user. It could also be a toggle switch/button in the
interface. We would need to create some kind of volume control interface
too for the individual outputs.

If you're doing individual outputs per compressor band, just use the
make-up gain as your output. The range is limited, but that's fine; if
you're doing huge gain modifications at that point in the signal chain,
you're doing it wrong! :-)

Post by Patrick Shirkey
How would we handle the compressors/limiters for each individual band?

That's a tricky question. Could we have a 'tab' for each band? I've
never coded a GUI so I don't know how much complexity that would add.

[Michiel Broek]

Post by Patrick Shirkey

Post by Michiel Broek

Post by Patrick Shirkey

Post by Michiel Broek

Post by Patrick Shirkey

Post by Michiel Broek
I see it like this. A unit for live sound is adjusted once for the
combination of speaker units and amplifiers. Then only minor teaks may
be needed for certain halls, but in most cases it's not necessary.
If
all is adjusted, lock the unit and bury the password. There is a reason
why these DSP's have so few knobs.
Mastering is different, each song is different and even the same song
can be made different just by tuning Jamin. Jamin does a good job and
works well combined with Ardour.
I see it as two whole different things even if a lot of processing is
the same.

Post by Patrick Shirkey

Post by Michiel Broek
But if someone would decide to go ahead building a solution for live
sound, then I would like to see that happen in a fork of Jamin instead
of trying to build all in one application.

I don't understand why you would request a fork. Jamin hasn't
changed
for
several years so making some additions is hardly a big deal. If you wanted
to continue using the older interface there could even be a "classic"
interface for people with that specific need.
Multiple interfaces for multiple uses. Jamin as a mastering tool for live
and post prod. Makes sense to me to have it all in one place. A flexible
and highly customisable solution for audio quality. The sound engineers
best friend on or off stage...

I guess if I would design a software DSP based on Jamin technology, I
still would like it to be so that no one passing by that computer can
change any setting. It's just needed once and is mostly stacked away in
the amp racks too, so it's not in range of the FOH mixer.

In order to achieve something like this with jamin we need a daemon mode.
There is one thing in the way of that at the moment. It also affects the
"presets" ui mode (-g). Basically the hdeq requires to be realized at
least once before everything will work as expected. The hack is to
realize the main window then hide it but in daemon mode we don't want to
realize any windows.
Jan do you have any tips on how to bypass "realizing" the hdeq. I notice
we have the heq_pixmap for offscreen drawable so it looks like we are
pretty close already.

Based on these ideas I would suggest to split it in two parts. The
daemon that does the processing and listens on a network socket for a
controlling app.
Build the controller app and let in communicate over the network. Then
you have the full freedom to install everything on one machine, or run
headless, or run remote controlled. For local use, use named sockets only.

We already have osc support so we might not need a new socket. I think we
can add a flag for remote controlling the daemon via the existing
interface.
I'm not completely across OSC though so if anyone has a suggestion for the
best way to handle it functionally please let me know.
FYI, I have managed to get past the issue of "realizing" the hdeq widget.
Turns out that the update_meters() function was the culprit.
I'm looking at the Daemon mode now and then I will make an update to cvs
for others to test out...

Patrick, for some ideas about live units,
http://www.dbxpro.com/en-US/product_families/driverack
The building blocks in Jamin are there, but I think you need a lot of
configuration options to get to one of these dbx units.

What would you say we are missing at the moment that is the most obvious
feature to include in a live processing unit?

Delay's in each output for speaker alignment. 0 up to 10 mSec in small
steps would do. For easy setup, the readout should be in inches/feet or
centimeters. For the rest it is all a kind of plugable system, like
stereo in, stereo low mid and high out, or mono subs, two bands. Or six
bands and then you need to link two units, In software this can be just
one unit if the host can handle that.

Most hardware units have a smaller eq (31 bands) then Jamin has. In
addition there are notch filters on some of them to suppress feedback. I
hate that but sometimes you really need them. The current eq can do that
too so I think you won't need to add that.

There are also units that have an input delay for larger ranges. That's
only useful for very large venues where you place extra stacks away from
the main stage. But it can be useful in small theaters as well if you
have extra speakers on a balcony or something like that. More for fixed
systems but it can be a nice addition.

Maybe you need to add something like startup Jamin in different modes
(Mastering/Live) or let it startup in the last configured setup.



gtx, Mchiel

Post by Patrick Shirkey
--
Patrick Shirkey
Boost Hardware Ltd
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel

[David Nielson]

Post by Michiel Broek
Delay's in each output for speaker alignment.

Oh yeah, that too :-P

BTW, if Jamin exports extra ports for each compressor band, you don't
need to offer the option of re-combining them. Connect multiple outputs
to the same JACK port and save yourself that trouble.

(So for my two-way system with a crossover frequency of 200 Hz, I'd have
three bands, and send the top two to the highs and the bottom one to the
lows; or, you can set the top crossover frequency to 24 KHz so it
effectively doesn't exist.)

David

[Michiel Broek]

Post by David Nielson

Post by Michiel Broek
Delay's in each output for speaker alignment.

Oh yeah, that too :-P
BTW, if Jamin exports extra ports for each compressor band, you don't
need to offer the option of re-combining them. Connect multiple outputs
to the same JACK port and save yourself that trouble.
(So for my two-way system with a crossover frequency of 200 Hz, I'd have
three bands, and send the top two to the highs and the bottom one to the
lows; or, you can set the top crossover frequency to 24 KHz so it
effectively doesn't exist.)

David,

Hardware units can run in a two band mode, then two outputs are just
not used. In Jamint it can be easier, delete two outputs and have only
one crossover frequency. Or add two outpust and have a stereo 4 band
crossover.

With Jack it can be dynamic.

gtx, Michiel.

[Patrick Shirkey]

Post by Michiel Broek

Post by Patrick Shirkey

Post by Michiel Broek

Post by Patrick Shirkey

Post by Michiel Broek

Post by Patrick Shirkey

Post by Michiel Broek
I see it like this. A unit for live sound is adjusted once for the
combination of speaker units and amplifiers. Then only minor teaks may
be needed for certain halls, but in most cases it's not necessary.
If
all is adjusted, lock the unit and bury the password. There is a reason
why these DSP's have so few knobs.
Mastering is different, each song is different and even the same song
can be made different just by tuning Jamin. Jamin does a good job and
works well combined with Ardour.
I see it as two whole different things even if a lot of processing is
the same.

Post by Patrick Shirkey

Post by Michiel Broek
But if someone would decide to go ahead building a solution for live
sound, then I would like to see that happen in a fork of Jamin instead
of trying to build all in one application.

I don't understand why you would request a fork. Jamin hasn't
changed
for
several years so making some additions is hardly a big deal. If
you
wanted
to continue using the older interface there could even be a "classic"
interface for people with that specific need.
Multiple interfaces for multiple uses. Jamin as a mastering tool
for
live
and post prod. Makes sense to me to have it all in one place. A flexible
and highly customisable solution for audio quality. The sound engineers
best friend on or off stage...

I guess if I would design a software DSP based on Jamin technology, I
still would like it to be so that no one passing by that computer can
change any setting. It's just needed once and is mostly stacked
away
in
the amp racks too, so it's not in range of the FOH mixer.

In order to achieve something like this with jamin we need a daemon mode.
There is one thing in the way of that at the moment. It also affects the
"presets" ui mode (-g). Basically the hdeq requires to be realized at
least once before everything will work as expected. The hack is to
realize the main window then hide it but in daemon mode we don't
want
to
realize any windows.
Jan do you have any tips on how to bypass "realizing" the hdeq. I notice
we have the heq_pixmap for offscreen drawable so it looks like we are
pretty close already.

Based on these ideas I would suggest to split it in two parts. The
daemon that does the processing and listens on a network socket for a
controlling app.
Build the controller app and let in communicate over the network. Then
you have the full freedom to install everything on one machine, or run
headless, or run remote controlled. For local use, use named sockets only.

We already have osc support so we might not need a new socket. I think we
can add a flag for remote controlling the daemon via the existing
interface.
I'm not completely across OSC though so if anyone has a suggestion for the
best way to handle it functionally please let me know.
FYI, I have managed to get past the issue of "realizing" the hdeq widget.
Turns out that the update_meters() function was the culprit.
I'm looking at the Daemon mode now and then I will make an update to cvs
for others to test out...

Patrick, for some ideas about live units,
http://www.dbxpro.com/en-US/product_families/driverack
The building blocks in Jamin are there, but I think you need a lot of
configuration options to get to one of these dbx units.

What would you say we are missing at the moment that is the most obvious
feature to include in a live processing unit?

Delay's in each output for speaker alignment. 0 up to 10 mSec in small
steps would do. For easy setup, the readout should be in inches/feet or
centimeters. For the rest it is all a kind of plugable system, like
stereo in, stereo low mid and high out, or mono subs, two bands. Or six
bands and then you need to link two units, In software this can be just
one unit if the host can handle that.

Delays are easy to add. We have several plugins available for that.

What I am seeing is the following signal chain:

input -> stereo ->eq -> 32/1024 band -> xover

|-> pre aux -> ->individual stereo channels -> volume control -> jack out
|-> compressors -> stereo -> limiter -> volume -> stereo out
|-> compressors-> post aux -> individual stereo channels -> volume control
-> jack out
|-> compressors -> limiters -> individual stereo channels -> volume
control -> multiple jack outs

That provides a decent amount of flexibility but limits us to a maximum of
3 stereo channels of output.

To give us more channels we would need to add support for more compressor
chains. I'm not sure how the xover would be affected by having more than 3
output paths. What is the general method for dealing with that case?

Post by Michiel Broek
Most hardware units have a smaller eq (31 bands) then Jamin has. In
addition there are notch filters on some of them to suppress feedback. I
hate that but sometimes you really need them. The current eq can do that
too so I think you won't need to add that.
There are also units that have an input delay for larger ranges. That's
only useful for very large venues where you place extra stacks away from
the main stage. But it can be useful in small theaters as well if you
have extra speakers on a balcony or something like that. More for fixed
systems but it can be a nice addition.

We can add an input delay but currently we only have stereo inputs. Is
there a need for more?

Post by Michiel Broek
Maybe you need to add something like startup Jamin in different modes
(Mastering/Live) or let it startup in the last configured setup.

Than is easy enough to add. We already have three modes:

Classic
Presets
Daemon

It is entirely reasonable to add a few more like:

Quad output
Live - 6 channel
5.1 - surround
5.1 + 2 - surround
5.1 + 2 over stereo - "Dolby E" broadcast format
Ambisonic output







--
Patrick Shirkey
Boost Hardware Ltd

[David Nielson]

Post by Michiel Broek
David,
Hardware units can run in a two band mode, then two outputs are just
not used. In Jamint it can be easier, delete two outputs and have only
one crossover frequency. Or add two outputs and have a stereo 4 band
crossover.

Yes. What I'm saying is that Jamin doesn't need to handle it *at all*.
Just set the number of bands to as many as you think you might need; if
a user needs fewer bands, connect the different outputs to the same
output ports in JACK. JACK combines them, and you effectively have a
smaller number of bands.

(With the advantage that you could have different settings for different
'sub-bands'. Your crossover could also act as a de-esser, for example.)

Post by Michiel Broek
That provides a decent amount of flexibility but limits us to a maximum of
3 stereo channels of output.
To give us more channels we would need to add support for more compressor
chains. I'm not sure how the xover would be affected by having more than 3
output paths. What is the general method for dealing with that case?
We can add an input delay but currently we only have stereo inputs. Is
there a need for more?

Need? No; IMO it should be on a 'roadmap', if there is one. It should be
lower-priority than providing per-compressor outputs. (Again IMO.)

Post by Michiel Broek
Classic
Presets
Daemon
Quad output
Live - 6 channel
5.1 - surround
5.1 + 2 - surround
5.1 + 2 over stereo - "Dolby E" broadcast format
Ambisonic output

These options are orthogonal to each other. A mastering engineer, live
engineer, or desktop user with a DIY 5.1 system (and too much time on
their hands) might want to use any of the three 'modes' with any of
those channel combinations / arrangements.

David

[Patrick Shirkey]

Post by David Nielson

Post by Michiel Broek
David,
Hardware units can run in a two band mode, then two outputs are just
not used. In Jamint it can be easier, delete two outputs and have only
one crossover frequency. Or add two outputs and have a stereo 4 band
crossover.

Yes. What I'm saying is that Jamin doesn't need to handle it *at all*.
Just set the number of bands to as many as you think you might need; if
a user needs fewer bands, connect the different outputs to the same
output ports in JACK. JACK combines them, and you effectively have a
smaller number of bands.
(With the advantage that you could have different settings for different
'sub-bands'. Your crossover could also act as a de-esser, for example.)

Your suggestion builds on the 3 band output extension by adding multiple
band outputs. I'm happy to look into this once I have the three bands
working.

I suppose it is just a case of adding additional sliders for each band and
giving them their own compressor+delay+limiter+volume control? Do we need
to have some kind of sane limit to the number of bands in the xover?

For the UI we can add an extra panel to the master window and extend the
total height or we can add a tabbed panel to each compressor to display
the delay+limiter+volume+jack output.

Finally for this use case we also can sum the output to a master stereo
out at the end of the process for extra i/o goodness.

In the case of 3 xover bands we will end up with a total of 3 x stereo
channels low/mid/high and 1 x master stereo channel.

Post by David Nielson

Post by Michiel Broek
That provides a decent amount of flexibility but limits us to a maximum of
3 stereo channels of output.
To give us more channels we would need to add support for more compressor
chains. I'm not sure how the xover would be affected by having more than 3
output paths. What is the general method for dealing with that case?
We can add an input delay but currently we only have stereo inputs. Is
there a need for more?

Need? No; IMO it should be on a 'roadmap', if there is one. It should be
lower-priority than providing per-compressor outputs. (Again IMO.)

Post by Michiel Broek
Classic
Presets
Daemon
Quad output
Live - 6 channel
5.1 - surround
5.1 + 2 - surround
5.1 + 2 over stereo - "Dolby E" broadcast format
Ambisonic output

These options are orthogonal to each other. A mastering engineer, live
engineer, or desktop user with a DIY 5.1 system (and too much time on
their hands) might want to use any of the three 'modes' with any of
those channel combinations / arrangements.
David
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel

--
Patrick Shirkey
Boost Hardware Ltd

[Michiel Broek]

On 02/05/2013 05:55 PM, Patrick Shirkey wrote:

Hi Patrick,


Just delete a lot.

Post by Patrick Shirkey
Delays are easy to add. We have several plugins available for that.
input -> stereo ->eq -> 32/1024 band -> xover
|-> pre aux -> ->individual stereo channels -> volume control -> jack out
|-> compressors -> stereo -> limiter -> volume -> stereo out
|-> compressors-> post aux -> individual stereo channels -> volume control
-> jack out
|-> compressors -> limiters -> individual stereo channels -> volume
control -> multiple jack outs

At the stereo out level you would have:


xover-out-lo level delay limiter output
xover-out-mi level delay limiter output
xover-out-hi level delay limiter output

And that for left and right. No compressors in the output drivers, just
limiters to protect the speakers.
You draw the compressors before the stereo out/xover, that is a good
place in the chain.

If you use the usual 3 band compressor that is now in Jamin, then please
note that the crossovers for the multiband compressor have different
frequencies then the crossovers in the output stages. The compressors
have more a functional choice of the crossover frequency, while the
output crossovers are dictated by the speaker systems. It could be more
or less then three output drivers and even just one if you should drive
a full-range system.

Now that I wrote this down, it looks more an extension of the existing
Jamin with extra outputs via crossovers, then a change in the original
Jamin design.

Post by Patrick Shirkey
That provides a decent amount of flexibility but limits us to a maximum of
3 stereo channels of output.
To give us more channels we would need to add support for more compressor
chains. I'm not sure how the xover would be affected by having more than 3
output paths. What is the general method for dealing with that case?

That is not needed, jus leav it that way and add the extra outputs.

Post by Patrick Shirkey

Post by Michiel Broek
Most hardware units have a smaller eq (31 bands) then Jamin has. In
addition there are notch filters on some of them to suppress feedback. I
hate that but sometimes you really need them. The current eq can do that
too so I think you won't need to add that.
There are also units that have an input delay for larger ranges. That's
only useful for very large venues where you place extra stacks away from
the main stage. But it can be useful in small theaters as well if you
have extra speakers on a balcony or something like that. More for fixed
systems but it can be a nice addition.

We can add an input delay but currently we only have stereo inputs. Is
there a need for more?

I don't think so. The idea is to chain these processors, but they can be
fed from one stereo source. The main unit does not need a delay, but
units with amps and speakers further away from the stage need a delay
to prevent echo effects for the audience. However, this can be done with
a number of jack-racks with a delay plugin too. Or make jamin allow for
extra plugins in the input stage.


gtx, Michiel.

[Patrick Shirkey]

Post by Michiel Broek
Hi Patrick,
Just delete a lot.

Post by Patrick Shirkey
Delays are easy to add. We have several plugins available for that.
input -> stereo ->eq -> 32/1024 band -> xover
|-> pre aux -> ->individual stereo channels -> volume control -> jack out
|-> compressors -> stereo -> limiter -> volume -> stereo out
|-> compressors-> post aux -> individual stereo channels -> volume control
-> jack out
|-> compressors -> limiters -> individual stereo channels -> volume
control -> multiple jack outs

xover-out-lo level delay limiter output
xover-out-mi level delay limiter output
xover-out-hi level delay limiter output
And that for left and right. No compressors in the output drivers, just
limiters to protect the speakers.
You draw the compressors before the stereo out/xover, that is a good
place in the chain.
If you use the usual 3 band compressor that is now in Jamin, then please
note that the crossovers for the multiband compressor have different
frequencies then the crossovers in the output stages. The compressors
have more a functional choice of the crossover frequency, while the
output crossovers are dictated by the speaker systems. It could be more
or less then three output drivers and even just one if you should drive
a full-range system.

To be precise, the output values from the compressors are summed into a
stereo signal before being fed to the limiter. IIUC you are suggesting an
option to bypass the compressors completely and add individual delay +
limiters + stereo output for each band in the xover.

That is effectively the "pre aux" output mode.

For the "post aux" output mode are you suggesting an additional xover?

For both options I need to keep the 3 x stereo signals post
xover/compressor and send them to 3 x stereo jack outputs with 3 x stereo
delay+limiter+volume controls.

Both modes (pre/post aux) can be easily handled with the compressor bypass
toggles. Also we already have delays on the output for the low and mid
band compressors. So it seems that it would be useful to have more
advanced control of the settings directly in the main UI?

I'm thinking of the best way to handle that in the UI. We could add a
"tabbed" view to each compressor to display the delay control, limiter and
volume for each band by making the "delay" label clickable. Other
suggestions welcome.

I'm not sure why we don't have delay on the high band compressor. Does
anyone recall why that was not deemed necessary at the time?

Post by Michiel Broek
Now that I wrote this down, it looks more an extension of the existing
Jamin with extra outputs via crossovers, then a change in the original
Jamin design.

Post by Patrick Shirkey
That provides a decent amount of flexibility but limits us to a maximum of
3 stereo channels of output.
To give us more channels we would need to add support for more compressor
chains. I'm not sure how the xover would be affected by having more than 3
output paths. What is the general method for dealing with that case?

That is not needed, jus leav it that way and add the extra outputs.

Post by Patrick Shirkey

Post by Michiel Broek
Most hardware units have a smaller eq (31 bands) then Jamin has. In
addition there are notch filters on some of them to suppress feedback. I
hate that but sometimes you really need them. The current eq can do that
too so I think you won't need to add that.
There are also units that have an input delay for larger ranges. That's
only useful for very large venues where you place extra stacks away from
the main stage. But it can be useful in small theaters as well if you
have extra speakers on a balcony or something like that. More for fixed
systems but it can be a nice addition.

We can add an input delay but currently we only have stereo inputs. Is
there a need for more?

I don't think so. The idea is to chain these processors, but they can be
fed from one stereo source. The main unit does not need a delay, but
units with amps and speakers further away from the stage need a delay
to prevent echo effects for the audience. However, this can be done with
a number of jack-racks with a delay plugin too. Or make jamin allow for
extra plugins in the input stage.

--
Patrick Shirkey
Boost Hardware Ltd

[David Nielson]

Post by Patrick Shirkey
I'm thinking of the best way to handle that in the UI. We could add a
"tabbed" view to each compressor to display the delay control, limiter and
volume for each band by making the "delay" label clickable. Other
suggestions welcome.

Sounds ideal to me. Though if you put them in tabs, you could make all
the controls available all the time, so long as the right tab is selected.

Post by Patrick Shirkey
I suppose it is just a case of adding additional sliders for each
band and giving them their own compressor+delay+limiter+volume
control? Do we need to have some kind of sane limit to the number of
bands in the xover?

Yes, I believe you're right.

We've got two people suggesting 8... *I* can't imagine needing more than
8 bands, but I hate to be Bill Gates saying 640k ought to be enough for
anybody ;-)

At the same time, the range of human hearing isn't getting bigger...
What do you think?

David

[Patrick Shirkey]

Post by David Nielson

Post by Patrick Shirkey
I'm thinking of the best way to handle that in the UI. We could add a
"tabbed" view to each compressor to display the delay control, limiter and
volume for each band by making the "delay" label clickable. Other
suggestions welcome.

Sounds ideal to me. Though if you put them in tabs, you could make all
the controls available all the time, so long as the right tab is selected.

Post by Patrick Shirkey
I suppose it is just a case of adding additional sliders for each
band and giving them their own compressor+delay+limiter+volume
control? Do we need to have some kind of sane limit to the number of
bands in the xover?

Yes, I believe you're right.
We've got two people suggesting 8... *I* can't imagine needing more than
8 bands, but I hate to be Bill Gates saying 640k ought to be enough for
anybody ;-)

Just to confirm, by 8 band we are talking about 4 x stereo so we would
have 4 compressors instead of three.

Would we need more xover bands if we gave the option to increase the
number of EQ bands from 1024 upto 16384? Looking at the code it should be
fine to do that as long as the total is a power of 2 and more than 32.

Post by David Nielson
At the same time, the range of human hearing isn't getting bigger...
What do you think?
David
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel

--
Patrick Shirkey
Boost Hardware Ltd

[David Nielson]

Post by Patrick Shirkey

Post by David Nielson

Post by Patrick Shirkey
I'm thinking of the best way to handle that in the UI. We could add a
"tabbed" view to each compressor to display the delay control, limiter and
volume for each band by making the "delay" label clickable. Other
suggestions welcome.

Sounds ideal to me. Though if you put them in tabs, you could make all
the controls available all the time, so long as the right tab is selected.

Post by Patrick Shirkey
I suppose it is just a case of adding additional sliders for each
band and giving them their own compressor+delay+limiter+volume
control? Do we need to have some kind of sane limit to the number of
bands in the xover?

Yes, I believe you're right.
We've got two people suggesting 8... *I* can't imagine needing more than
8 bands, but I hate to be Bill Gates saying 640k ought to be enough for
anybody ;-)

Just to confirm, by 8 band we are talking about 4 x stereo so we would
have 4 compressors instead of three.

Hmm, I'm not sure what the other fellow meant, but I meant 8 compressors
for a grand total of 16 outputs under stereo operation.

Post by Patrick Shirkey
Would we need more xover bands if we gave the option to increase the
number of EQ bands from 1024 upto 16384? Looking at the code it should be
fine to do that as long as the total is a power of 2 and more than 32.

16384-band EQ... can you imagine the things you could do...

David

[Michiel Broek]

Post by David Nielson

Post by Patrick Shirkey

Post by David Nielson

Post by Patrick Shirkey
I'm thinking of the best way to handle that in the UI. We could add a
"tabbed" view to each compressor to display the delay control, limiter and
volume for each band by making the "delay" label clickable. Other
suggestions welcome.

Sounds ideal to me. Though if you put them in tabs, you could make all
the controls available all the time, so long as the right tab is selected.

Post by Patrick Shirkey
I suppose it is just a case of adding additional sliders for each
band and giving them their own compressor+delay+limiter+volume
control? Do we need to have some kind of sane limit to the number of
bands in the xover?

Yes, I believe you're right.
We've got two people suggesting 8... *I* can't imagine needing more than
8 bands, but I hate to be Bill Gates saying 640k ought to be enough for
anybody ;-)

Just to confirm, by 8 band we are talking about 4 x stereo so we would
have 4 compressors instead of three.

Hmm, I'm not sure what the other fellow meant, but I meant 8 compressors
for a grand total of 16 outputs under stereo operation.

Post by Patrick Shirkey
Would we need more xover bands if we gave the option to increase the
number of EQ bands from 1024 upto 16384? Looking at the code it should be
fine to do that as long as the total is a power of 2 and more than 32.

16384-band EQ... can you imagine the things you could do...
David
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel

Hi David and Patrick,


I think we have all different ideas how this would look like. My idea
was this:

Take the original Jamin without any significant changes. Behind the
stereo outputs comes a new (second) crossover, that should be selectable
in 2 to 8 bands. Personally 8 is too much, but I see people want it so
let's make it 8. That means 8 x 2 outputs.
Between the output of that second crossover and real jack output there
should be a level control, a 0 to 10 mSec delay and a hard limiter. That
limiter would be synced between left/right on the same band but not
linked with the other bands. The limiter should have a bypass and
threshold. There is no compressor needed in the last stage, dynamics
should be done at the beginning in the original Jamin part.
Ah, and a level meter on the output.

Should the whole thing be able to do 5 or 7 channels audio? Movie makers
may want that.

The crossover frequencies in the original part with compressors that
form the original Mastering thing should stay as it is. Maybe an option
to make it more then three bands as we now have.

The crossover frequencies on the second (new) stage are defined by the
speaker systems that the new stereo outputs are driving.

If you think about all this, it could be a pluggable design. The user
designs what goes in the signal path and where.

I also see a lot of problems here in the UI design and remote control,
but that should be solvable somehow.


gtx, Michiel.

[Patrick Shirkey]

Post by Michiel Broek

Post by David Nielson

Post by Patrick Shirkey

Post by David Nielson

Post by Patrick Shirkey
I'm thinking of the best way to handle that in the UI. We could add a
"tabbed" view to each compressor to display the delay control,
limiter
and
volume for each band by making the "delay" label clickable. Other
suggestions welcome.

Sounds ideal to me. Though if you put them in tabs, you could make all
the controls available all the time, so long as the right tab is selected.

Post by Patrick Shirkey
I suppose it is just a case of adding additional sliders for each
band and giving them their own compressor+delay+limiter+volume
control? Do we need to have some kind of sane limit to the number

of

Post by Patrick Shirkey
bands in the xover?

Yes, I believe you're right.
We've got two people suggesting 8... *I* can't imagine needing more than
8 bands, but I hate to be Bill Gates saying 640k ought to be enough for
anybody ;-)

Just to confirm, by 8 band we are talking about 4 x stereo so we would
have 4 compressors instead of three.

Hmm, I'm not sure what the other fellow meant, but I meant 8 compressors
for a grand total of 16 outputs under stereo operation.

Post by Patrick Shirkey
Would we need more xover bands if we gave the option to increase the
number of EQ bands from 1024 upto 16384? Looking at the code it should be
fine to do that as long as the total is a power of 2 and more than 32.

16384-band EQ... can you imagine the things you could do...
David
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel

Hi David and Patrick,
I think we have all different ideas how this would look like. My idea
Take the original Jamin without any significant changes. Behind the
stereo outputs comes a new (second) crossover, that should be selectable
in 2 to 8 bands. Personally 8 is too much, but I see people want it so
let's make it 8. That means 8 x 2 outputs.

Ok, I'm seeing the functionality now. Thanks for explaining so concisely.

Post by Michiel Broek
Between the output of that second crossover and real jack output there
should be a level control, a 0 to 10 mSec delay and a hard limiter. That
limiter would be synced between left/right on the same band but not
linked with the other bands. The limiter should have a bypass and
threshold. There is no compressor needed in the last stage, dynamics
should be done at the beginning in the original Jamin part.
Ah, and a level meter on the output.
Should the whole thing be able to do 5 or 7 channels audio? Movie makers
may want that.
The crossover frequencies in the original part with compressors that
form the original Mastering thing should stay as it is. Maybe an option
to make it more then three bands as we now have.

So we are basically looking at a whole new lower panel for the "live"
system compared to the "classic" mode.

Post by Michiel Broek
The crossover frequencies on the second (new) stage are defined by the
speaker systems that the new stereo outputs are driving.
If you think about all this, it could be a pluggable design. The user
designs what goes in the signal path and where.
I also see a lot of problems here in the UI design and remote control,
but that should be solvable somehow.

It's not too bad actually. Just time and testing.

[Michiel Broek]

Hi Patrick,

Post by Patrick Shirkey

Post by Michiel Broek

Post by David Nielson

Post by Patrick Shirkey

Post by David Nielson

Post by Patrick Shirkey
I'm thinking of the best way to handle that in the UI. We could add a
"tabbed" view to each compressor to display the delay control,
limiter
and
volume for each band by making the "delay" label clickable. Other
suggestions welcome.

Sounds ideal to me. Though if you put them in tabs, you could make all
the controls available all the time, so long as the right tab is selected.

Post by Patrick Shirkey
I suppose it is just a case of adding additional sliders for each
band and giving them their own compressor+delay+limiter+volume
control? Do we need to have some kind of sane limit to the number

of

Post by Patrick Shirkey
bands in the xover?

Yes, I believe you're right.
We've got two people suggesting 8... *I* can't imagine needing more than
8 bands, but I hate to be Bill Gates saying 640k ought to be enough for
anybody ;-)

Just to confirm, by 8 band we are talking about 4 x stereo so we would
have 4 compressors instead of three.

Hmm, I'm not sure what the other fellow meant, but I meant 8 compressors
for a grand total of 16 outputs under stereo operation.

Post by Patrick Shirkey
Would we need more xover bands if we gave the option to increase the
number of EQ bands from 1024 upto 16384? Looking at the code it should be
fine to do that as long as the total is a power of 2 and more than 32.

16384-band EQ... can you imagine the things you could do...
David
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel

Hi David and Patrick,
I think we have all different ideas how this would look like. My idea
Take the original Jamin without any significant changes. Behind the
stereo outputs comes a new (second) crossover, that should be selectable
in 2 to 8 bands. Personally 8 is too much, but I see people want it so
let's make it 8. That means 8 x 2 outputs.

Ok, I'm seeing the functionality now. Thanks for explaining so concisely.

No problem.

Post by Patrick Shirkey

Post by Michiel Broek
Between the output of that second crossover and real jack output there
should be a level control, a 0 to 10 mSec delay and a hard limiter. That
limiter would be synced between left/right on the same band but not
linked with the other bands. The limiter should have a bypass and
threshold. There is no compressor needed in the last stage, dynamics
should be done at the beginning in the original Jamin part.
Ah, and a level meter on the output.
Should the whole thing be able to do 5 or 7 channels audio? Movie makers
may want that.
The crossover frequencies in the original part with compressors that
form the original Mastering thing should stay as it is. Maybe an option
to make it more then three bands as we now have.

So we are basically looking at a whole new lower panel for the "live"
system compared to the "classic" mode.

Yes it does.

Post by Patrick Shirkey

Post by Michiel Broek
The crossover frequencies on the second (new) stage are defined by the
speaker systems that the new stereo outputs are driving.
If you think about all this, it could be a pluggable design. The user
designs what goes in the signal path and where.
I also see a lot of problems here in the UI design and remote control,
but that should be solvable somehow.

It's not too bad actually. Just time and testing.

[Hoggins!]

Hello everyone,

We are using Jamin on an FM transmitter site to get the best output
power, and to comply with regulations. This is working really well.
It is okay to have a slight delay in the processing. Jamin is hooked on
a jack system with 512 latency(not a realtime kernel, though).

Actually, we would need two things :
- Aheadless system
- More bands(8?)

Processingpower is not an issue here, si I believe the DSP should be at
ease, even with more bands.
A headless system, allowing us to remotely control all the settings with
a GUI would be a lot of fun ! And it would make us avoid using a VNC
server, just to run Jamin.

Just our thoughts !

Hoggins!

Post by Patrick Shirkey
What would you say we are missing at the moment that is the most obvious
feature to include in a live processing unit?

[Patrick Shirkey]

Post by Hoggins!
Hello everyone,
We are using Jamin on an FM transmitter site to get the best output
power, and to comply with regulations. This is working really well.
It is okay to have a slight delay in the processing. Jamin is hooked on
a jack system with 512 latency(not a realtime kernel, though).
- Aheadless system
- More bands(8?)

I'm happy to look at the but how should we handle the xover functionality?

Post by Hoggins!
Processingpower is not an issue here, si I believe the DSP should be at
ease, even with more bands.
A headless system, allowing us to remotely control all the settings with
a GUI would be a lot of fun ! And it would make us avoid using a VNC
server, just to run Jamin.

Please give the new "Daemon" mode a try on your system? It should allow
remote control with a combination of osc and netjack. I'm looking into the
code to see how the osc functionality is intended to work. Does anyone
else have any experience with OSC midi controls on jack?

I'm still thinking on the interface. It will probably have to be a
stripped back version of the "classic" interface as I don't think we can
reliably transmit the realtime signal levels across the network.

Any suggestions for functionality in the remote interface are welcome.

Post by Hoggins!
Just our thoughts !
Hoggins!

Post by Patrick Shirkey
What would you say we are missing at the moment that is the most obvious
feature to include in a live processing unit?

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel

--
Patrick Shirkey
Boost Hardware Ltd

[Patrick Shirkey]

Post by John Rigg

Post by John Rigg

Post by John Rigg
Personally I would hesitate to use JAMin for live sound as it has

quite

Post by John Rigg
a lot of latency - certainly enough to cause problems for performers

if

Post by John Rigg
used on monitor sends, and possibly also enough to cause phase

problems

Post by John Rigg
between direct sound from the stage and the PA speakers.

I guess the question is what kind of live performance use is the intention?
It's also possible to use Jamin as an fx box instead of a mastering tool...
IIRC internal latency is about as good as it gets but maybe there are
improvements or tradeoffs that could be added for live use?

I haven't measured the latency, but operating the bypass button does
make the timing jump by enough to make me think it could be a problem for
live musicians. Anything much over 10ms total can cause timing problems
for some musicians. That's about the time it takes sound to travel 10 feet,
which might appear insignificant, but I do know musicians for whom this
could be an issue. Increase that to 20ms total and it's potentially a
problem for just about any musician trying to play in time with others on
a small stage. That much delay between back line sound and PA speakers
could also be quite noticeable.
Without measurements this is all conjecture of course. If I get time I'll
try to do some tests.
There's nothing unreasonable about the OP's feature request BTW. It could
be useful in situations where latency isn't a problem, like playing
pre-recorded music, but that isn't what I usually think of as live
sound ;-)

I guess we could do a pre and post compressor output option. It's just a
case of hooking up a couple more jack outputs to the signal chain.

I can see tow options for enabling it in the interface:

1: Add 12 new jack outputs for pre and post
2: Add 6 new outputs for pre and post and provide a "pre/post" aux/send
toggle.

We could also add volumen sliders for the output on each send so that
would probably require a secondary window or a panel that could be hidden
and slide in/out if in use.

Any thoughts on UI functionality?

I might have some time to add this over the next month.



--
Patrick Shirkey
Boost Hardware Ltd

[Gilberto Borges]

Hello.

I have a presets package posted here:

jamin-***@lists.sourceforge.net

Thank you.

--- Em ter, 5/2/13, Udo van den Heuvel <***@xs4all.nl> escreveu:

De: Udo van den Heuvel <***@xs4all.nl>
Assunto: Re: [Jamin] Feature Request JAMin
Para: "Patrick Shirkey" <***@boosthardware.com>
Cc: jamin-***@lists.sourceforge.net
Data: Terça-feira, 5 de Fevereiro de 2013, 10:08

Post by Patrick Shirkey
We already have osc support so we might not need a new socket. I think we
can add a flag for remote controlling the daemon via the existing
interface.

Small question:
Where on the web is the howto to enable OSC in Jamin?

Kind regards,
Udo

[Udo van den Heuvel]

Yes, I believe I made an rpm out of those, but are they OSC related?

I found I need liblo. Is that enough?

Udo

[Patrick Shirkey]

Post by Gilberto Borges
Hello.

Do you mind digging out that link again?

I'll use them for my test suite :-)

Post by Gilberto Borges
Thank you.
Assunto: Re: [Jamin] Feature Request JAMin
Data: Terça-feira, 5 de Fevereiro de 2013, 10:08

Post by Patrick Shirkey
We already have osc support so we might not need a new socket. I think we
can add a flag for remote controlling the daemon via the existing
interface.

Where on the web is the howto to enable OSC in Jamin?
Kind regards,
Udo
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel

--
Patrick Shirkey
Boost Hardware Ltd

[Udo van den Heuvel]

Post by Patrick Shirkey

Post by Gilberto Borges
Hello.

Do you mind digging out that link again?

It's no longer (?) at http://musix.codigolivre.org.br/?q=node/7 ...

Udo