Hello, Jeannette--
Thank you for the reply.
it's not a formant filter. It's a reed pipe with a resonator. Wikipedia
> has this to say - and probably to show on the matter:
> https://en.wikipedia.org/w/index.php?title=Vox_humana
>
My apologies, Jeannette. "Formant filter" was a little misleading on
purpose, more like bait. But now that a couple people have bit, i'll be
more accurate. Ralf's link to organ stops contains a good demonstration of
a vox humana:
http://www.organstops.org/_sounds/CulverAcademy/VoxHumanaArpeg.mp3
It does change formants slightly, but nowhere near as dramatically as the
basilica organ. So then, how did the boys from Weingarten accomplish such
a drastic change in vowels?
i've found a highly technical article on reed pipes. It may be above my
head, but i'll try to read it before forwarding the link.
Thank you, again, Jeannette! Please take care.
Tom
Hi,
I don't know what solved the issue, but actually the output sound is
ok. It's still not in the same class as RME, but from good hifi quality.
For the cable plugged into channel 2 of the Focusrite only tip
and sleeve are soldered.
For the cable plugged into channel 1 of the Focusrite only tip
and sleeve are soldered, too, but by a crocodile clip cable I connected
and disconnected ring with sleeve [1].
There's neither a difference in volume, nor in tone, with ring and
sleeve short circuit or not.
A big surprise was, that comparing the output of the Focusrite, with
the output of a CD player, everything was ok yesterday, when the
testing was done. I couldn't reproduce the bad sound I experienced
before. The output level of the Focusrite was ok as well. No other
analog audio cables were connected to the other channels. Perhaps some
of the other audio cables, connected to other outputs caused problems by
the tests, I made a while ago.
However, this morning I checked channels 3, 5, 7 and 9 against channel
2, again with a short circuit and without it and after that I compared
channels 4, 6, 8 and 10 with channel 9, but only without a short
circuit. And finally I repeated to compare channel 1 and 2 with a CD
player. Everything sounded very well.
With linux 4.9.0-rt1 it's possible to go down to 32 frames at 48 KHz,
getting lots of inaudible xruns, at 16 frames as well as 64 frames the
interface is completely unusable. At 128 frames it's the same as for a
vanilla kernel with threadirqs, just scrolling with the USB mouse wheel
in roxterm usually does cause issues, very seldom a random xrun could
happen, when switching to another window. At 256 frames it seems to be
absolutely stable, however, it seems to be usable at 128 frames, with
linux-rt as well as a vanilla linux with threadirqs. FWIW using another
USB cable at 128 frames doesn't make a difference. Actually it even
seems to be usable at 32 frames, the xruns were inaudible. I don't know
why it's completely broken at 64 frames. 16 and 64 frames cause long
interrupted audio signals.
Regards,
Ralf
[1] http://picpaste.com/pics/IMG_2250_unbalanced.1484895640.jpg
Hi lista :)
Using an i3 <https://i3wm.org/docs/userguide.html#exec> shortcut, I can
control my jack transport from everywhere, even when no jack application
has focus :
bindsym $mod+p exec echo play | jack_transport
bindsym $mod+Shift+p exec echo stop | jack_transport
Thanks to FalkTX for the pipe trick BTW, I saw that on linuxmusicians ;
This is very cool if you have some sort of wireless keyboard, but as you
can see it's two different keystrokes, how do I make it so <command>
toggles play/pause? Alternatively, how do I know when jack transport is
rolling, so I can hack my way into making my own toggle script? I did my
homework and read the inline --help of all the available jack commands
on my machine :
⚡ jack_
jack_alias jack_freewheel jack_monitor_client
jack_simple_client
jack_bufsize jack_iodelay jack_multiple_metro
jack_simple_session_client
jack_capture jack_latent_client
jack_net_master jack_test
jack_capture_gui jack_load jack_net_slave jack_thru
jack_connect jack_lsp jack_netsource
jack_transport
jack_control jack_metro jack_rec
jack_unload
jack_cpu jack_midi_dump jack_samplerate
jack_wait
jack_cpu_load jack_midi_latency_test
jack_server_control jack_zombie
jack_disconnect jack_midiseq jack_session_notify
jack_evmon jack_midisine jack_showtime
But found no way to detect the transport status ; Is there a way to know
it?
yPhil
--
Yassin Philip - New album out NOW
http://yassinphilip.bitbucket.org
Hi,
Any recommendations on a USB to MIDI interface that plays nice with JACK?
I have the MIDI on my AF12, but that's way overkill for most of the MIDI
I/O I need to do.
Regards,
Mac
DrumGizmo version 0.9.12 now available!
Get it at http://www.drumgizmo.org/
DrumGizmo is an open source, multichannel, multilayered, cross-platform
drum plugin and stand-alone application. It enables you to compose drums
in midi and mix them with a multichannel approach. It is comparable to
that of mixing a real drumkit that has been recorded with a multimic setup.
Most prominent new feature is that we now have FreeBSD support! Several
fixes for various combinations of software also made it into this
release. Check the roadmap for 0.9.12[1] for full details.
Important note to package maintainers:
Since version 0.9.11 we copy vst source files into the build tree while
building the vst plugin. This mean that should you wish to make a
tar-ball available with the build directory after the build has finished
this must either be stripped of said files or not be made public.
[1]:
http://www.drumgizmo.org/wiki/doku.php?id=roadmap:features_roadmap#version_…
On Thu, 19 Jan 2017 16:33:42 +0100, Georg Krause wrote:
>https://answers.microsoft.com/de-de/windows/forum/windows_10-hardware/upgra…
>
>https://www.sequencer.de/synthesizer/viewtopic.php?t=46422
Thank you,
I forward it to the list, just in case somebody understands German,
too. FWIW the second link is about a name issue. This issue exists also
for Linux and not only for USB interfaces. I own two PCI EWX 24/96
cards. It's not possible to give them individual MIDI names, so it's
impossible to automatically store and restore MIDI connections.
Regards,
Ralf
On Jan 18, 2017 05:10, Bill Gribble <grib(a)billgribble.com> wrote:
>
> On 01/18/2017 09:40 AM, Mac wrote:
>
> > Hi,
> >
> > Any recommendations on a USB to MIDI interface that plays nice with JACK?
>
> I have a Roland UM-One stuck in my cable bag. USB on one end, "Y" to a
> MIDI DIN in and out, lump in the middle the size of a matchbox. I
> usually have it plugged into a DSI Mopho and I have never had trouble
> with it.
I have an M-Audio MidiSport 1x1 that works with no problems at all. IIRC, there are other MidiSports with more ports that also work flawlessly with Linux and JACKD.
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
MFP -- Music For Programmers
Release 0.06
I'm pleased to announce a new version of MFP, mostly consisting
of bug fixes and improvements. It's been about 2 years since the
0.05 release, but lately I have been pretty energized!
A summary of changes is below. Please see GitHub for complete
details:
http://github.com/bgribble/mfp
This version is still source-code-only, but the new build system
should make it a bit easier for those who would like to try it.
Significant changes since release v0.05
----------------------------------------
* Build issues reported for the 0.05 release have been
fixed or mitigated
* Clarification of semantics around names and namespaces
(scopes)
* A change to send/receive semantics may break patches saved with
earlier versions of mfp, if they make use of vias and scopes
* New demo patches and fixes to old ones
* Improvements to performance, stability and error handling
* Left-side tabs and bottom-edge console/log can be toggled
with ` and ~ respectively
* Better default color selections, and the ability to set
per-object style (colors, fonts) in your patches
* Many other bugfixes and improvements. The complete list of
tickets closed since the 0.05 release is in the 0.06
milestone:
http://github.com/bgribble/mfp/issues?q=milestone%3A%22mfp+0.06%22+is%3Aclo…
About MFP
----------------------------------------
MFP is an environment for visually composing computer programs,
with an emphasis on music and real-time audio synthesis and
analysis. It's very much inspired by Miller Puckette's Pure Data
(pd) and Max/MSP, with a bit of LabView and TouchOSC for good
measure. It is targeted at musicians, recording engineers, and
software developers who like the "patching" dataflow metaphor for
coding up audio synthesis, processing, and analysis.
MFP is a completely new code base, written in Python and C, with
a Clutter UI. It has been under development by a solo developer
(me!), as a spare-time project for several years.
Compared to Pure Data, its nearest relative, MFP is superficially
pretty similar but differs in a few key ways:
* MFP uses Python data natively. Any literal data entered in the
UI is parsed by the Python evaluator, and any Python value is a
legitimate "message" on the dataflow network. This makes it much
easier to make patches that work like conventional "programs".
* MFP provides fairly raw access to Python constructs if desired.
For example, the built-in Python console allows live coding of
Python functions as patch elements at runtime.
* Name resolution and namespacing are addressed more robustly,
with explicit support for lexical scoping. This allows patches
to have dynamic or parameterized content, with hygienic
layer copying preserving lexical structure without name
collisions
* The UI is largely keyboard-driven, with a modal input system
that feels a bit like vim. The graphical presentation is a
single-window style with layers rather than multiple windows.
* There is fairly deep integration of Open Sound Control (OSC), with
every patch element having an OSC address and the ability to learn
any other desired address. MIDI controller learning is also robustly
supported.
* MFP has just a fraction of the builtin and addon functionality
provided by PD. It's not up to being a replacement except in
very limited cases!
The code and issue tracker are hosted on GitHub:
https://github.com/bgribble/mfp
You can find the LAC-2013 paper and accompanying screenshots,
some sample patches, and a few other bits of documentation in the
doc directory of the GitHub repo. The README files at the top
level of the source tree contain dependency, build, and
getting-started information.
More sample patches are in my personal patch repo:
https://github.com/bgribble/mfp-patches
Where's it going?
----------------------------------------
I've been working on MFP as a spare time project for almost 7
years now. The likelihood that it will ever have more than a few
users is low. Luckily, that doesn't bother me much; MFP is a
tool I am building mainly for my own use and education.
That being said, if there's something about it that appeals to
you, I welcome your interest and participation.
Thanks,
Bill Gribble <grib(a)billgribble.com>
On 01/17/2017 09:31 AM, john gibby wrote:
> I think my AVS implementation is not using Jack2. (I say this b/c I
> tried to use the -S option for synchronous running, and jackd didn't
> recognize it.) From what I read, seems worth it to install Jack2, so
> I plan to do that... unless you think a bad idea :)
>
> That zita-Irx software looks, well, incredibly rich. I guess I may
> try to switch to it instead of ecasound... Amazing, all these great
> resources in the Linux world...
>
> Thanks again,
> John
>
>
> On Tue, Jan 17, 2017 at 6:17 AM, Tweed <tweed(a)lollipopfactory.com
> <mailto:tweed@lollipopfactory.com>> wrote:
>
> On 01/17/2017 04:35 AM, john gibby wrote:
>> Sound is via ALC 1150 chipset; I don't think that's the problem.
>> When I go directly from pianoteq to alsa there's no problem; can
>> use even a 64 sample buffer. Maybe I need a little help in
>> killing the default jack server and starting it back (with dummy
>> back end ) using direct jackd command line instead of using
>> qjackctl? Then I think it may keep my specified buffer size. Am
>> Linux newby, takes a little work! :)
>>
>> On Jan 17, 2017 4:23 AM, "Jeanette C." <julien(a)mail.upb.de
>> <mailto:julien@mail.upb.de>> wrote:
>>
>> Jan 17 2017, john gibby has written:
>> ...
>>
>> When qjackctl brings up
>> the jack server, the buffer size gets overridden to
>> 1024; I see the message
>> in the log. What am I doing wrong? Is Jack the wrong
>> approach, when it is
>> ecasound, not jack, that writes to alsa?
>>
>> Hi John,
>> it appears that your soundcard is the problem. I've only
>> started JACK on
>> the commandline or through a dedicated start script, not
>> using qjackctl
>> or other JACK-supplied tools. But if you give a buffersize to
>> JACK it
>> will honour that buffersize, if the soundcard can stand it. I
>> haven't
>> seen an application before that couldn't honour JACK's
>> buffersize,
>> whatever it is. Especially Ecasound can certainly go down to
>> 64 samples.
>>
>> What soundcard do you have? Have you tried starting JACK for your
>> soundcard on the commandline and see what happens?
>> jackd --timeout 4500 -R -d alsa -d hw:0 -p 128
>> Assuming that your soundcard is the first one (hw:0).
>>
>> I have no experience with Pianoteq, but since it is meant as
>> a realtime
>> app, it should make sure that its sounds are played back
>> without delay
>> or with minimal delay. 128 and even 64 samples aren't that
>> uncommon.
>> ...
>>
>> Best wishes,
>>
>> Jeanette
>>
>> --------
>> When you need someone, you just turn around and I will be
>> there <3
>>
>>
>>
>> _______________________________________________
>> Linux-audio-user mailing list
>> Linux-audio-user(a)lists.linuxaudio.org
>> <mailto:Linux-audio-user@lists.linuxaudio.org>
>> http://lists.linuxaudio.org/listinfo/linux-audio-user
>> <http://lists.linuxaudio.org/listinfo/linux-audio-user>
>
> maybe a jackdbus thing? if you're using jack2, what does
> "jack_control status" show?
>
> if it says "started", do "jack_control stop" then try your jack
> command/qjackctl.
>
> --
> www.the-temp-agency.com/lollipop-factory
> <http://www.the-temp-agency.com/lollipop-factory>
>
> _______________________________________________ Linux-audio-user
> mailing list Linux-audio-user(a)lists.linuxaudio.org
> <mailto:Linux-audio-user@lists.linuxaudio.org>
> http://lists.linuxaudio.org/listinfo/linux-audio-user
> <http://lists.linuxaudio.org/listinfo/linux-audio-user>
>
If jackd doesn't recognize "-S" then its jack1. whats jackd -v show.
0.12x is jack1, 1.9.x is jack2. If you have jack1 its not a dbus
issue. maybe another running audio process (alsa-loop daemon?
pulse-jack whatever its called?) not allowing jackd to stop(not sure if
thats right tho seems like I've seen this with aj-snapshot). I use
jack2 (unrelated reasons). I don't know anything about avs linux (I
first thought you meant Av-Linux - a great audio distro), be careful
when changing out one JACK for another as your package manager may try
to remove things you don't want removed. Anyway, there shouldn't be any
reason related to your problem that you need to switch JACK1 <> JACK2.
Try to close any jack clients then stop the jack server. at this point
you should be able to stop jack with qjackctl if not, killall jackd on
command line. "top" or "htop" or "ps -ef | grep jackd" to see if
jackd has stopped or not. once you confirm jackd has stopped, try to run
your ecasound command.
--
www.the-temp-agency.com/lollipop-factory
