RFT: implementation of MOTU FireWire series CueMix DSP and CueMix FX
Hi all,
After investigation for protocols of MOTU FireWire series including
features of CueMix DSP and CueMix FX, I've written implementation
corresponding to the features in snd-firewire-ctl-services project[1].
If you are enough interested in it, would you please test the
implementation?
The first aim of this test request is to check whether the protocol
implementation works as well out of my development environment.
# Disclaimer
* The aim of the work is to reveal relevant protocols so adequately and
write the implementation. It is out of my scope to produce user-friendly
applications such as GUI with cool user-delighted look and feel. (This
is also the reason that the message is so long for general users.)
# Acknowledgment
When I made investigation plan for the protocols and evaluated the result
of investigation, documents included in ffado source code[13] is helpful.
The documentation includes a part of the result, while some parts are
newly revealed in this time. I appreciate for document writers.
# Current status
* Below models are supported and I tested
* 828
* 896
* 828mk2
* 896hd
* 8 pre
* Ultralite
* 4 pre
* Audio Express
* 828mk3 (FireWire only/Hybrid)
* Ultralite mk3 (FireWire only/Hybrid)
* The most of control functions are available via ALSA control interface
* Hardware metering support
* Interaction support between on-board control component such as knob,
utilizing notification mechanism of ALSA control interface
# Requirements
For the test, you need to solve long list of requirements since the
protocol implementation is new and lays down user space as well as kernel
space. I'm sorry for testers to discourage your motivation, but they are
required...
* Linux kernel v5.13 or later
* a commit 66c6d1ef86ff ('ALSA: control: Add memory consumption limit to
user controls')[2] is required since many user-defined control element
sets are used.
* Installation of backport codes for ALSA firewire stack
* They comes from Linux kernel v5.16 prepatch (not released yet).
* Please follow to instructions in my remote repository[3]
* Installation of alsa-gobject v0.2.1 or later.
* alsa-gobject project[4] provides libraries which perform as glue for
several kind of language bindings to use UAPI of Linux sound subsystem.
For detail, please refer to release announcement[5].
* Installation of libhinawa topic branch
* libhinawa project[6] also provides library as glue for UAPI of ALSA
firewire stack.
* The topic branch (topic/motu-mixer-ioctl)[7] includes new APIs to use
functions added in the kernel v5.16 prepatch.
* Rust v1.51 or later
* I use Rust programming language for the protocol implementation in user
space side.
* Build topic branch of snd-firewire-ctl-services
* snd-firewire-ctl-services project[8] includes the series of
implementation for protocols specific to ASICs/Vendors/Models.
Additionally, as reference of service programs, it includes runtime
implementation based on ALSA control interface and ALSA Sequencer
interface.
* The topic branch ('topic/motu-mixer-ioctl') includes implementation
for the test.
# Test procedure
When the above requirements are satisfied, the service program can be build
by below command line. It takes a bit long than compiling with C language
since Rust compiler does more work than C (mainly due to type inference and
lifetime check for safe runtime).
$ cargo build -p snd-firewire-ctl-services
The service program for MOTU FireWire series runs by below command line:
$ cargo run --bin snd-firewire-motu-ctl-service CARD_ID
The CARD_ID is the numeric ID of sound card corresponding to your device.
You need to load ALSA firewire-motu driver in advance:
$ sudo modprobe snd-firewire-motu
$ cat /proc/asound/cards
...
2 [UltraLiteMk3 ]: FW-MOTU - UltraLiteMk3
MOTU UltraLiteMk3 (version:100800), GUID ...
In the above example, CARD_ID should be 2.
When the service program runs, you can see control elements via ALSA
control interface. You can operate them by usual tools of ALSA control
application, but I prefer 'qashctl' in 'qastools' project[11].
Due to specification of protocols defined by MOTU, notifications from the
device for some controls are firstly available when isochronous packets
are transmitted by the device. Please run any of ALSA PCM applications
when testing.
The aim of the request is whether the service program can be built and run
out of my development environment. So I don't expect you so much. However,
If you are interested, please check the other parts about which I concern:
* The range of value for each control is valid or not.
* Inverse evaluation of each control with boolean value.
* The lack of control which should be produced by the service program.
# Filing issues
* Please use issue service in github.com[10].
* Preferable issues
* The service program aborts when I operate control A.
* The service program doesn't interact with on-board operation B.
* The service program looks to be frozen when I operate C.
* The behaviour of control element D is odd.
* Unexpected issues
* Why device A is not supported
* It's preferable for you to take your time to cooperate with me if you
wish. It might take a long time since the implementation lays down
user space and kernel space.
* If so, please file the issue to my remote repository for kernel
prepatch[12].
* Why we have no GUI with cool look and feel
* It's your work. The GUI application might be an ALSA control
application which interacts with the service program.
* I can not get which control value corresponds to actual ports
* It is restriction under current design of ALSA control interface.
We need to work for any extension to the design.
* The name of control B is not user-friendly.
* The name of controls are not fixed yet since we have few name
convention for controls in studio-use equipments. It might
corresponds to discussion in ALSA upstream. In my opinion,
Linux audio developers have been enough lazy to the issue for
recent decade.
[1] https://github.com/alsa-project/snd-firewire-ctl-services/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
[3] https://github.com/takaswie/snd-firewire-improve
[4] https://github.com/alsa-project/alsa-gobject/
[5] https://lore.kernel.org/alsa-devel/20200623093239.GA68404@workstation/
[6[ https://github.com/alsa-project/libhinawa
[7] https://github.com/alsa-project/libhinawa/tree/topic/motu-mixer-ioctl
[8] https://github.com/alsa-project/snd-firewire-ctl-services/
[9] https://github.com/alsa-project/snd-firewire-ctl-services/tree/topic/motu-m…
[10] https://github.com/alsa-project/snd-firewire-ctl-services/issues
[11] https://gitlab.com/sebholt/qastools
[12] https://github.com/takaswie/snd-firewire-improve/issues
[13] https://web.archive.org/web/20110704073441/http://subversion.ffado.org/brow…
Cheers
Takashi Sakamoto
Sorry to _low_show - this was meant for the list.
On Mon, Oct 11, 2021 at 03:19:45PM +0200, _low_show wrote:
> Looks great, will make some time to try it out! Thanks for making this!
I somehow deleted the original post, but refer to
> https://youtu.be/51eHCA4oCEI
> https://lv2plug.in/book
I never got to grips with turtle. In particular not with
things like:
@prefix doap: <http://usefulinc.com/ns/doap#> .
@prefix lv2: <http://lv2plug.in/ns/lv2core#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix units: <http://lv2plug.in/ns/extensions/units#> .
All docs and tutorials I found mention that the URLs do NOT
mean that an application reading a file that contains them
would actually need to read them from the web (which would
be a unacceptable security risk anyway).
But that means that whatever is defined by those URLs
must actually be hard-coded in any LV2 host that reads
the 'manifest.ttl' or 'my-plugin.ttl' files.
Which raises the question why those @prefix lines are
required at all. They could be used in theory to check
that what is hard-coded corresponds to what is defined
in those URLs. But to do that the application would
need to access them.
So all that these lines seem to provide is some illusion
of conformity which isn't enforced or checked at all.
So the conclusion is that this isn't any better than any
ad-hoc way of encoding the plugin metadata.
Or am I missing something essential ?
TIA for any reply that would enlighten me...
--
FA
Hi all!
I have recently released first preview of SoundTracker v1.0.3. Here are
new features of this pre-release:
* General:
- Indication of the current playing instrument / sample number in scopes
(optional via Settings)
- On new instrument or sample loading ins / sample name(s) can be
overwritten or kept (configurable via Settings -> GUI settings)
- Extended pattern sequence editor with DND (activaled by right-click on
the playlist area)
* Instrument editor:
- Envelopes cutting / copying / pasting / scaling
- Indication of the keys playing with the current instrument also in the
pattern / song playing mode
* Track editor:
- Track line insertion / removal
- Masking for cut / copy / paste operaions
I invite everyone to test this pre-release and look forward your
feedback (bugreports and feature requests).
Download: https://sourceforge.net/projects/soundtracker/files/
Regards,
Yury.
Looks great, will make some time to try it out! Thanks for making this!
On Mon, 11 Oct 2021, at 12:00, linux-audio-dev-request(a)lists.linuxaudio.org wrote:
> Send Linux-audio-dev mailing list submissions to
> linux-audio-dev(a)lists.linuxaudio.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
> or, via email, send a message with subject or body 'help' to
> linux-audio-dev-request(a)lists.linuxaudio.org
>
> You can reach the person managing the list at
> linux-audio-dev-owner(a)lists.linuxaudio.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linux-audio-dev digest..."
>
>
> Today's Topics:
>
> 1. Programming LV2 plugin from scratch tutorial video series
> (Sven Jaehnichen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 10 Oct 2021 13:58:57 +0200
> From: Sven Jaehnichen <sjaehn(a)jahnichen.de>
> To: linux-audio-announce(a)lists.linuxaudio.org,
> linux-audio-dev(a)lists.linuxaudio.org, devel(a)lists.lv2plug.in
> Subject: [LAD] Programming LV2 plugin from scratch tutorial video
> series
> Message-ID: <bd239f3c-c8d5-f4fa-d1b2-bb5525ff8a2a(a)jahnichen.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi,
>
> I started with a programming tutorial series about making LV2 plugins.
> Really from scratch. Dedicated for beginners.
>
> I read in chats from so many hobbyist and bedroom producers that that
> they want to make LV2 plugins but they don't have any idea how to start.
> The most of them have got some basic programming experience. With Java,
> Python, Javascript, or maybe some basic C/C++. I want to take them by my
> hand and want to guide them to make some LV2 plugins. Step by step. I'm
> also going to explain technical aspects. The turtle language, how LV2
> plugins work, what is realtime, and so on.
>
> The first videos are online:
>
> https://youtu.be/51eHCA4oCEI
>
> Two more are already pre-produced, and will follow within the next weeks.
>
> In addition, there's a great resource by David called LV2 book
> https://lv2plug.in/book/ which helped me to start just a few years ago.
>
> Please give me some feedback. And I'm open for any suggestion.
>
> Regards,
> Sven
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>
> ------------------------------
>
> End of Linux-audio-dev Digest, Vol 176, Issue 2
> ***********************************************
>
Hi,
I started with a programming tutorial series about making LV2 plugins.
Really from scratch. Dedicated for beginners.
I read in chats from so many hobbyist and bedroom producers that that
they want to make LV2 plugins but they don't have any idea how to start.
The most of them have got some basic programming experience. With Java,
Python, Javascript, or maybe some basic C/C++. I want to take them by my
hand and want to guide them to make some LV2 plugins. Step by step. I'm
also going to explain technical aspects. The turtle language, how LV2
plugins work, what is realtime, and so on.
The first videos are online:
https://youtu.be/51eHCA4oCEI
Two more are already pre-produced, and will follow within the next weeks.
In addition, there's a great resource by David called LV2 book
https://lv2plug.in/book/ which helped me to start just a few years ago.
Please give me some feedback. And I'm open for any suggestion.
Regards,
Sven