Hi,
is it correct that the following two scenarios give the exact same result?
(digital audio signal) -> (record) -> (playback) -> (apply fx) -> (result)
(digital audio signal) -> (apply fx) -> (record) -> (playback) -> (result)
regards
Tom
> Partly also for historical reasons, I think. In many ways digital
> recording started as the "poor man's tape". Direct to disk recording with
> no effects was at first all that could be handled and most peole using it
> were replacing 8 track tape with it. They already had a mixer. As the DAW
> developed, mix down on the computer has been next. But for many people the
> recording part of the strip has been outside of the DAW, on an analog
> mixer. This is changing as a new batch of people are going mic->
> interface. Their input strip is whatever the interface provides... often
> only trim (either as a pot on the pre or in ALSA).
Is this for convenience or not having the ability to afford something else?
I think a lot of times money is spent on the wrong thing such as buying a
fancy multicore computer when something from 8 years ago is totally adequate
for digital audio.
>
> So digital recording is
> also going through a two mixer to inline transition. From hybrid to
> digital only. The trim controls are there, where they should be, as close
> to incoming signal as possible. I don't suppose it would be too hard to
> add alsa trim for a card like the d1010 to ardour, but many USB IFs (even
> PCIe) have no controls in alsa. It is a physical pot somewhere. So rather
> than being in front of the engineer, it is hidden and easily missed by the
> newby... or even not so new. So much is done digitally, that the remaining
> analog items are forgotten. This is a real problem with a two input IF,
> The trim needs to be set every time and the variety of signals through one
> channel is huge. Everything from a ribbon to line level. Having a set of
> good pre amps could be worth while, this is probably the biggest hole in
> the hobby studio. I have two, tube and solid state. (plus line)
It is very simple to keep a few notes on what is a good preamp setting for
a given mic and preamp combination. One inconvenience with some budget
preamps is that you don't know what sort of gain it is providing, so while you
may write down the setting by using a notation like 2:00 for dial position,
you haven't learned anything about gain, so if you swap out a preamp you need
to guess at where to start.
You can get into trouble with a mismatch between preamp and converters, such that
you are trying to "maximize bits" by getting a hot signal level into your converters.
The preamp ends up distorting and you have a hi-res recording of a distorted sound!
I actually had this problem with a remake of a vintage preamp. So it seems every
preamp has a voltage sweet spot that it should be operated in.
The best situation is if you have converters with analog trims, which is I think
what you were saying, and set them accordingly for each preamp. I leave my preamps
plugged into a specific A/D channels that have been calibrated for that preamp.
One other note, some budget preamps are not qualified for certain levels of input.
I have a Presonus Audiobox which can sound fine for an acoustic guitar, but throw a
drum at it and it is automatically over full scale and unusable.
Grekim
> On 09/03/2014 04:04 PM, Raphaël BOLLEN wrote:
>> Hello,
>>
>> I'm trying to use jack_set_xrun_callback to be notified in my
>> application of eventual xrun.
>>
>> in the documentation of the function I see a note: that 'this function
>> cannot be called while the client is activated'.
>>
>> Does it mean that my client must call jack_set_xrun_callback before
>> being activated
>
> Yes. First set the callback, and only later call jack_activate().
>
>
> Two tiny jack clients which may come in handy:
>
> * jackxrun: report x-runs on the command line
> * busyjack: create artificial load
>
> http://gareus.org/gitweb/?p=jackfreqd.git;a=tree;f=tools;
> gcc -o jackxrun jackxrun.c -ljack
> gcc -o busyjack busyjack.c -ljack
>
> ./jackxrun # reports xruns in the terminal
> ./busyjack 90 # will ramp things up to 90% DSP load (default is 50)
>
> It can be used to create x-runs, yet it's not the same as a x-run from hw.
>
> [..]
>> It says return 0 on success. Does it mean the callback must succeed.
>
> Your callback function must return 0.
>
> Cheers!
> robin
Thanks Robin for your explanations and tools.
I think the x-runs (one every few hours) I get are due to hardware because jack_cpu_load is < 5% and
system load average < 0.2 all periods. The problem is that those xruns make the process thread jump
to 100% cpu and the process disappears from QJackctl, although jack and other clients still run
normally. The code also runs fine on another computer.
I'm currently testing with jack priority raised from 40 to 70 to be above irq threads. I did not yet
have an xrun in this config but It's a bit early to conclude.
I will also try busyjack.
Best regards
--
Raphaël.
Hi, I'd like to get some feedback here in LAD.
On September 3, 2014 07:44:55 PM Fons Adriaensen wrote:
>> On Wed, Sep 03, 2014 at 11:57:05AM -0700, J. Liles wrote:
> > (when I go from recording to mixing I usually change the JACK buffer
> > size... is NSM supposed to do this for me automatically? I don't see how
> > or why it would).
> RE switching buffer sizes, if your system works reliably with some
> size, there is no reason to use a larger one.
Did Paul say recently Jack's buffer size change system was never implemented?
Do I recall correctly that there is no way to switch?
Is the difficulty with internals, or conceptually? Or compatibility - how about:
If any client in the graph doesn't implement the callback or the callback
returns false, simply don't switch buffer size. Zero compatibility issues?
*** Usage Scenario 1:
You start your favourite DAW with what seems a moderate Jack buffer size.
As you work, you start adding effects to various tracks.
But you go too far, adding one too many CPU intensive plugins,
say Phase Vocoders and so on, and now you have at best xruns,
at worst slowness/freezing.
Now you must shut the app down, shut Jack down, adjust Jack's buffer size,
restart Jack, restart the application.
In light of the Pulse-on-Jack-QJackCtl threads these steps may not be easy.
Pushing an app button to be able to quickly switch to a higher buffer size
would be cool !
*** Usage Scenario 2:
J. Liles pretty much just said what I wanted to say:
During (but not limited to) recording, if you require to be able to monitor
one or more live inputs, low latency small buffers are absolutely required.
When I say monitor, I mean WITH effects plugins, otherwise hardware
monitoring can be used.
Here the DAW is being used as BOTH a recorder and an effects unit.
I do it a lot and it's a PITA to have to keep restarting with a new size.
After recording, when live input is no longer needed, we no longer care
about the buffer size and in fact DEMAND high latency higher buffer sizes.
The caveat here is that when switching to the 'live' low-latency mode,
we often have to first turn off some CPU-hungry plugins (non-essential on
playback tracks) and save the song before switching, otherwise after the
switch the app is slow/locked/frozen.
Then after switching back to non-live high-latency mode, we can safely
turn on those plugins again.
So we absolutely need those higher buffer sizes too sometimes.
I've been dreaming of having such a dual 'mode' switch in MusE.
>From lazy to tight at the push of a button.
Possible?
Thanks.
Tim.
Hello,
I'm trying to use jack_set_xrun_callback to be notified in my application of eventual xrun.
in the documentation of the function I see a note: that 'this function cannot be called while the
client is activated'.
Does it mean that my client must call jack_set_xrun_callback before being activated or that the
callback cannot be called while client is activated? If it's the later than should I use another
client that will stay not activated as parameter jack_client_t
It says return 0 on success. Does it mean the callback must succeed doing something or can it just
increase some counter and return 0. What would be the consequences of a non-zero error code? Would
jack stop?
Currently I'm registering the callback and then activate and use the client. I'm not sure if I get
an xrun that does crash my application of if something wrong in the application makes it crash and
trigger an xrun... Chicken and egg problem.
Is there another way?
Thanks
--
Raphaël.
for reference: from jack.h
/**
* Tell the JACK server to call @a xrun_callback whenever there is a
* xrun, passing @a arg as a parameter.
*
* All "notification events" are received in a seperated non RT thread,
* the code in the supplied function does not need to be
* suitable for real-time execution.
*
* NOTE: this function cannot be called while the client is activated
* (after jack_activate has been called.)
*
* @return 0 on success, otherwise a non-zero error code
*/
int jack_set_xrun_callback (jack_client_t *client,
JackXRunCallback xrun_callback, void *arg) JACK_OPTIONAL_WEAK_EXPORT;
Hi Ralph,
You didn't really read my post didn't you? You are slghtly off-topic, it reads like the catalogus of a keyboard shop. Look at the name of this forum. Linux: that is about software. Developers: that
are people interested in creating something new, not in purchaging all kinds of gear.
Still: thanks for the information.
W.
On 08/28/2014 11:53 AM, Ralf Mardorf wrote:
> Programming a sound using what kind of synthesis ever needs knowledge
> and many parameters. But there's another way to easily make new sounds
> based on existing sounds. E.g the Yamaha TG33's joystick, the vector
> control records a mixing sequence, where the volume and/or the tuning of
> 4 sound can be mixed. Since you mentioned touch screens, Alchemy for the
> iPad allows to morph sounds by touching the screen similar to the
> joystick used by the TG33, but it also can be used to control filters,
> effects and arpeggiator. There already are several old school synth and
> AFAIK new workstations, especially new proprietary virtual synth that
> provide what you describes. Btw. 2 of the 4 TG33 sounds are FM sounds,
> not that advanced as provided by the DX7, the other two are AWM (sound
> samples). Regarding the complexity of DX7 sound programming, the biggest
> issue is that it has got no knobs. There are books about DX7
> programming, such as Yasuhiko Fukuda's, but IMO it's easier to learn by
> trail and error. JFTR e.g. the Roland Juno-106 provides just a few
> controllers, but you easily can get a lot of sounds, without much
> knowledge http://www.vintagesynth.com/roland/juno106.php , in theory
> this could be emulated by virtual synth, in practise the hardware allows
> to use specialized microchips that produce analog sound, that can't be
> emulated that easily, not to mention that at the end of the computers
> sound chain there always is a sound card, so if you emulate several
> synth with the same computer, it's not the same as having several real
> instruments, a B3, Minimoog etc..
>
>
Hi Gordon,
You are totally right, with one exception: the 2/3 harmonic (corresponding to a 12' pipe) is not weird-sounding, it sounds very nice and mellow, also while playing chords. I had the 'idea fix' that it
was common for Hammond and church organs also, but as you said: it does not exist there.
Wouter
On 09/01/2014 05:56 PM, gordonjcp(a)gjcp.net wrote:
> On Mon, Sep 01, 2014 at 05:44:08PM +0100, W.Boeke wrote:
>> Yes, I'm talking about adding lower frequencies. They don't sound shit(?), Hammond and organ players do it all the time.
> 2/3 would, because it doesn't "fit" nicely.
>
> If you look at the stops available on a Hammond your base generator is 8', with the option to add in a 16' "pipe" giving a partial one octave lower. There are straight octave partials at 4', 2' and 1' and then there are stops at a perfect fifth (5 1/3), an octave and a fifth (2 2/3), two octaves and a major third (1 3/5) and two octaves and a fifth (1 1/3).
>
> There isn't one at 2/3 (which would correspond to a 12' pipe). That would come out at a fourth below your fundamental, which would be a bit weird-sounding.
>
> Try it if you don't believe me.
>
Hi fellow audio developers,
This forum is apparently mainly about audio production. But there's another side regarding audio, and that is: how to create interesting and/or beautiful sounds in software? Many sound generating
programs try to emulate the sounds of vintage instruments as close as possible, sometimes with impressive results, but software has many more possibilities then electro-mechanic or early electronic
intruments.
I try to imagine how the Hammond organ was developed. There must have been a person with some ideas how he could generate organ-like sounds using spinning tone wheels, each capable to generate one
sine waveform, and to combine them using drawbars. Then he implemented this idea, listening carefully to the results, adding and removing different components. The key-clicks, caused by bouncing
contacts, formed a serious problem, however musicians seemed to like them, and they became part of the unique Hammond sound.
Compared to the available technical possibilities of the past, software designers nowadays have a much easier life. A computer and a MIDI keyboard is all you need, you can try all kinds of sound
creation, so why should you stick trying to reproduce the sounds of yore?
Maybe there are one or two eccentrics like me reading this post? In my opinion a software musical instrument must be controllable in a simple and intuitive way. So not a synthesizer with many knobs,
or an FM instrument with 4 operators and several envelope generators. You must be able to control the sounds while playing. A tablet (Android or iOS) would be an ideal control gadget. And: not only
sliders and knobs, but real-time, informative graphics.
As an example let me describe an algorithm that I implemented in a (open-source) program CT-Farfisa. I use virtual drawbars controlling the different harmonics (additive synthesis). The basic waveform
is not a sine, but also modelled with virtual drawbars. The basic waveform can have a duty cycle of 1, 0.7, 0.5 etcetera. The final waveform is shortened with the same amount. The beauty of this is
that you can control the duty cycle with the modulation wheel of the MIDI keyboard, so it's easy to modify the sound while playing. The program has build-in patches that have names of existing
instruments, but that's only meant as an indication: they do not sound very similar to those instruments. This description might sound a bit complicated, but coding it is not that difficult. Also
several attack sounds are provided, which is very important for the final result. The program has a touch-friendly interface, runs under Linux (for easy development and experimentation) and Android
(for playing).
It is not my aim to provide another software tool that you can download and use or not, but to exchange ideas about sound generation. I know there are many technics, e.g. wave guides, physical
modelling, granular synthesis, but I think that often it's difficult to control and modify the sound while playing, in an intuitive way. By the way, did you know that Yamaha, creator of the famous DX7
FM synth, had only 1 or 2 employees who could really program the instrument?
Wouter Boeke
Hi everyone,
Some of you might have noticed, we're having issues delivering mailing lists
posts to gmail users (it can be fairly random). I'm also having similar
issues at work and on my own server. It seems gmail has tightened their
filtering rules a bit and generate quite the amount of backscatter emails
which generally results in mailman accounts being disabled.
TL;DR
mailman issues, gmail sucks, I'm working on a fix :)
Cheers !
--
Marc-Olivier Barre
XMPP ID : marco(a)marcochapeau.org
www.MarcOChapeau.org
