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
My apologies, iOS mail doesn't provide mailing list replies and I tend to forget this.
> On 17 Jan 2017, at 09:40, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
>
>
>
>> On 16 Jan 2017, at 22:16, Jostein Chr. Andersen <jostein(a)vivaldi.net> wrote:
>>
>> On måndag 16 januari 2017 kl. 19:52:43 CET Fons Adriaensen wrote:
>>
>>
>>> I switched to Opera, having lost all trust in Chrome.
>>
>> It's starting to be OT, but:
>>
>> https://vivaldi.com :-)
>
> Oops, I didn't notice, that somebody replied earlier than I did.
Hello,
just been fighting with some jackd starting problems, and figured out that:
jackd --clocksource hpet <snip> produces an:
Unknown option character
error and fails to start, while the short option works:
jackd -c hpet <snip>
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 41000
creating alsa driver ...
hw:HAMMERFALL|hw:HAMMERFALL|1024|2|41000|0|0|nomon|swmeter|-|32bit
configuring for 41000Hz, period = 1024 frames (25.0 ms), buffer = 2 periods
.....
So nothing dramatic here, but if this happens not to be an arch linux
specific issue, maybe the manual page can be fixed with 0.126 or
whatever verion will follow.
Just felt like metioning it and maybe somebody can confirm this
behaviour. Or not.
