Greetings,
I'm pleased to announce the release of Non-DAW and Non-Mixer version
1.1.0. It's been a while since the last release. But, I assure you,
the project is still alive and well.
This release includes a number of fixes and some minor improvements to
the build system. The big changes are:
* Enhancements to the spatialization controls (which are automatically
provided for Ambisonics plugins).
* Support for the Non Session Manager.
* Enhancements to Control Sequences, OSC control signals can be sent
from Non-DAW to Non-Mixer. These connections will be preserved in
the session.
* Non-Mixer accepts input for all Module/Plugin controls via OSC.
* Non-Mixer can now import and export individual strips (including the
chain of modules and all their parameters!) This allows a workflow
on a higher level than presets.
* Updated visual styles for both Non-Mixer and Non-DAW. The 'Flat'
style has been greatly improved.
* New knob styles for Non-Mixer and knob style is a configuration
option rather than requiring editing the source.
* New icons in an assortment of sizes.
Additionally, Non now supports a robust new session management
protocol called NSM. A session management daemon is provided along
with a graphical interface called Non-Session-Manager. NSM represents
a significant leap forward for session management in Linux audio.
:: History of NSM
Way back in 2008, I became frustrated with the state of the art of
session management on Linux (a situation which has improved only
incrementally since that time). I ditched support for LASH, wrote a
lengthy post about Non-DAW's session management requirements to the
LAD mailing list, and started managing my sessions with shell scripts
and jack_snapshot. This eventually evolved into a session manager
written in Unix shell and using Unix FIFOs and regular files for
client control/communication. This system of session management was
tentatively called NASH (Non Audio Session Handler) and was never
released. In 2010, shortly after the release of Non-Mixer, I devised a
prototype version of the NSM OSC API and have been using it, still
unreleased and in prototype form, since then. The 2010 implementation
did not have a user interface and was controlled via shell scripts
using the `send_osc` command included in the distribution. Then, in
2012 (4 years later!), I was contacted by an enthusiastic power-user
regarding implementing OSC support in Non-Mixer. Since NSM uses OSC
for server<->client communication, I already had much of the OSC work
done and figured I might as well release it--and, while I was at it,
NSM. I then endeavored to simplify and document the NSM API,
discussing it at length with, and taking many suggestions from, Nedko
Arnaudov, the LADISH author. After implementing the
Non-Session-Manager FLTK GUI to control the session management daemon,
a new release became inevitable.
:: Bullet Points for NSM:
* Extremely fast and responsive control mechanism and user interface.
* The only dependency for clients and server is an OSC library (I use
liblo).
* Smart clients are able to switch projects without restarting.
* Clients can provide real-time status feedback to the server, and
therefor the user.
* The server stores all session data in per-session directories under
a configurable session root.
* Clients are forbidden to save or open files outside of the
per-session directory.
* The server provides simple template support in the form of
whole-session duplication.
* The Session management daemon is fully controllable via OSC.
* Strict user interface guidelines for a uniform and predictable
experience.
* The abstract session management API has no architectural requirement
for JACK, Xorg or any other subsystem (other than UDP
networking). This means that both headless daemons and programs
which are not JACK clients can be managed together in the same
session.
* A single session can be distributed across multiple machines on a
network.
* Multiple, independent, sessions can be opened on one machine at the
same time.
:: More About the NSM API
The latest NSM API documentation can be found at:
http://non.tuxfamily.org/nsm/API.html
NSM is included in the Non-DAW/Non-Mixer repository.
:: Ongoing and Future Development
Features that are in development for future releases include an
auto-learning and graphically re-mappable JACK MIDI<->OSC gateway
program tentatively named Non-OSC-MIDI-Mapper, which will simplify the
connection of bidirectional control surfaces such as the BCF2000 to
Non-Mixer. This program relies on Non's generic Control Signal layer
on top of OSC. So it's not necessarily generally useful (although, in
the future, it may be possible to use the `libmapper` library to
provide the same functionality in a somewhat standard way).
LV2 support is a frequently asked question. For various reasons, I
currently have no plans to host LV2 plugins in Non-Mixer. But if
anyone can come up with a compelling argument for LV2, or name one
existing (libre) LV2-only plugin which couldn't be ported to LADSPA in
a few hours that I couldn't live without having in Non-Mixer--I'd love
to hear about it.
I plan to re-factor Non-Sequencer to use the `nonlib` library common
to Non-DAW and Non-Mixer. This will eliminate some duplicated code and
allow for some of the user interface improvements seen in Non-DAW to
be implemented for Non-Sequencer. It will also enable various forms of
MIDI support in Non-DAW/Non-Mixer (it's not clear yet what forms this
support might take.)
Similarly, by using nonlib, OSC will be available in Non-Sequencer,
probably taking the form of OSC control for pattern triggers and
possibly pattern input. Also, with NSM's 'broadcast' capability, the
holy grail of a shared tempomap is closer than ever.
Another long-term goal for Non-Sequencer is to make the interface more
compatible with touchscreen use, which I am better equipped to tackle
now that I have a tablet like computer to play with.
A near term goal for Non-Mixer is to add an option to that causes all
mixer strips to run in a single JACK client. Conceptually, this is a
horrible idea, but due to some practical performance limitations of
JACK which affect users with hundreds of mixer strips, it may be a
necessary evil. Leave it to JACK to design and advertise a feature
(multiple clients per process) and then turn around and antagonize the
people who actually use it.
:: Project Notes
Please keep in mind that the Non project is a one man show. I designed
and implemented all of this stuff by my self, and at a considerable
cost in time, sleep and energy. I make it available to you so that you
can be free of the enormous burden of having to solve these complex
problems yourself. I see chatter on various forums about forking the
project, the project being dead, etc. Unlike some of the more
heavyweight projects out there, Non has no corporate sponsor, and I
have a complicated and turbulent existence which does not always allow
me to devote my attention to purely intellectual pursuits. I welcome
any and all contributions, whether they be in the form of code,
documentation, testing, package maintenance, chocolate, roses,
precious metals, priceless relics--whatever. If those who bring up the
issue of forking really had the skill and energy required to do
something better with Non-*, you'd think they'd at least try
submitting a few patches to me first...
I run Debian GNU/Linux and Non-* use a made-from-scratch custom build
system which relies on accurate information from pkg-config. I cannot
test on, or anticipate the quirks of, the hundreds of other Linux
distributions out there. I have a policy of never committing code to
the Non git repositories which does not build. Thus, if you are having
a problem building Non on your system, chances are it's just because
of some silly/simple quirk of the distribution you're using that could
easily be fixed. However, I'm not going to scour the web looking for
these reports. Unless you send a report to the appropriate Non-*
mailing list, expect that your issue will never be resolved. As
always, the best and fastest way to get anything fixed is to just fix
it yourself and sent me the patch--preferably with a thorough
explanation in the commit message of why it is needed and how it
works, as the less time I have to spend reviewing a patch, the quicker
it will be applied.
And finally, a note to packagers: If you feel that there's something
about Non's build system that you don't understand or feel like you
have to hack around, please consider discussing it with me. I'm more
than willing to make changes to the build system which make life
easier for packagers and improve the quality of packages. Having flaky
builds of Non-* in a distribution's packages isn't good for
anybody. I've seen comments in distributions' packaging bugtrackers
saying that Non is a dead project, that the "developers" (plural) are
unresponsive etc. But I've never heard from these people. If they
actually took the time to email me, they might have different
opinions.
:: Errata
I do not recommend linking Non-DAW against FLTK 1.3.0. FLTK 1.3.0
introduced a number of bugs, one of which seriously impairs Non-DAW's
graphics performance. Non-Sequencer and Non-Mixer do not use the
features of FLTK that have become buggy, so if you only plan to use
them 1.3.0 should be fine. 1.1.10, 1.1.9, and 1.1.7 work fine,
however.
In the future, I'll be maintaining a known-working version of FLTK
along with the Non repository so that Non-* can be statically linked
to the custom FLTK and avoid problems like this--and also allow many
workarounds used by the Non-* programs to be removed in preference to
fixing them at their source.
If you decide to build FLTK yourself, don't forget to use the
following configure options:
--enable-threads --enable-shared --enable-xft --enable-xdbe
-----
Non-DAW and Non-Mixer (and Non-Sequencer) can be acquired via git from
the URLs listed on the Non website:
http://non.tuxfamily.org
-----
The shortlog from v1.0.0 to v1.1.0 follows:
Jonathan Moore Liles (114):
Mixer: Don't use Fl_Group::clip_children(), which was only made
public in FLTK 1.1.10.
Fix a 64-bit bug in LADSPAInfo.
Fix another 64-bit bug in Module insertion.
Fix a mismerge that caused meter indicators not to be updated.
FL: Clip drawing of value of FL_Sometimes_Input when in non-input mode.
Mixer: Set minimum size for main window.
Mixer: Fix automatic row layout logic.
Mixer: Don't die if user picks a submenu node in module context menu.
Mixer: Destroy a module's parameter editor window when the
module itself is destroyed.
FL: Get rid of unnecessary call to clip_children().
Move non-daw scripts into timeline/ tree.
Mixer: Save/load the control mode status of the gain controller
as part of the mixer strip's state.
Mixer: Improve spatializer appearance.
Mixer: Report azimuth and elevation of panner points.
Mixer/Module_Parameter_Editor: Automatically show panner control
for module parameter pairs named Azimuth and Elevation.
Mixer/Panner: Vary width of latitude lines.
Module Parameter Editor: Don't use local allocation to store label.
Mixer: Further improve the appearance of the Panner widget.
Mixer: Fix azimuth/elevation reporting. Load current values in
Module_Parameter_Editor.
FL/Fl_Scalepack: Give scalepack the ability contain a resizable() child.
Mixer/Mixer: Cleanup.
Mixer: Auto-connect spatializer controls to spatialization plugins.
Mixer: Cleanup.
Mixer/Panner: Fix azimuth assignment.
Make spatialization mode of controller_module more robust.
Mixer/Module_Parameter_Editor: Don't point widow label at stack
allocation.
Mixer/Module_Parameter_Edtior: Silence compiler warnings.
Mixer: Raise (arbitrary) maximum number of channels of JACK
module from 6 to 16.
Mixer: Fix callback delivery by Controller Module.
Timeline: Fix 64-bit bug in interactive region trimming.
Fix 64-bit bug in peakfile handling.
Mixer: Explicitly link to libdl.
Fix build being broken by some include defining a preprocessor
macro for 'None'
Mixer: Don't segfault when removing a module.
Mixer: Don't segfault during teardown upon WM initiated exit.
Mixer: Handle WM main window close event just like Quit menu
comment (confirm save).
Some distributions put --as-needed in pkg-config and fltk-config
results. *See you in /dev/null*
Some distributions put --as-needed in pkg-config and fltk-config
results. *See you in /dev/null*
Really. I do.
Don't rely on 'Fl' symlink which only exists on Debian.
Mixer: Add basic OSC support.
Mixer: Add basic OSC control to Controller_Module.
Mixer: Add commandline option for specifying the OSC port to use.
Mixer: Allow clients to query for available OSC paths.
Mixer: Ensure that JACK_Module passes chain_name_changed event
to its Controllers.
Mixer: OSC enhancements. Responsd to both exact (range limited)
and Control Voltage (0.0-1.0 on */cv) input.
Mixer: Make OSC ports a property of Module::Port, not
Controller_Module. Therefore, all plugin parameters will be accessible
via OSC.
Mixer: Create unique OSC paths even when multiple instances of a
module/plugin with the same name exist in a chain.
OSC: Don't swallow up all parameterless messages.
Mixer: Feedback control values to OSC senders.
Mixer: Default OSC paths are CV. Use /unscaled for exact input.
Mixer: Don't create/destroy OSC ports more often than necessary.
Mixer: Update OSC paths upon chain/strip name change.
Mixer: Add OSC section to documentation.
Mixer: Display realtime parameter changes (initiated via
automation or GUI) in Module_Parameter_Editor
Mixer: Cleanup OSC value scaling/clamping behavior.
Mixer: Fix behavior issues of Toggle controls.
Mixer: Don't allow ',' in OSC paths.
Mixer: Fix mirroring and OSC automation of Spatialization controls.
Implement the Non-Session-Manager (NSM)
Mixer: Fix GUI update on Controller_Modules being controlled via JACK CV.
Mixer: Destroy instances of Controller_Module when the connected
modules are removed.
NSM: Process more than one message per wait cycle!
NSM: Detect death of clients whose processes are not children of NSMD.
NSM: Update documentation.
NSM: Fix logic when waiting for clients to load.
NSM: Support sessions spread across multiple servers.
OSC: Process all available events in one wait cycle.
Give Non-DAW the ability to detect Non-Mixer OSC servers via NSM
broadcast handshake.
OSC: Implement generic signal model with path auto discovery through NSM.
NSM: Mutli-server fixes.
Timeline: Don't die when not running under NSM.
Mixer: Don't die when not running under NSM.
FL: Fix an uninitialized value.
Mixer: Fix an invalid read on strip destruction due to a missing lock.
Don't poll NSM as frequently.
NSM: Clients must use the same protocol (UDP,TCP) as NSM server.
Timeline/Track: Avoid unnecessary drawing of occluded track box.
Timeline: Add interpolation mode choice of Linear and None to
Control Sequences.
OSC: Save and restore OSC signal connections outgoing from Non-DAW.
Timeline: Run OSC output in a dedicated thread.
Timeline: Clock cleanup.
OSC: Signal cleanups.
OSC: Improvements to signal routing.
Add libsigc++ as a dependency.
Big OSC signal cleanups
NSM: Add --detach option to nsmd.
NSM: Add session locking to nsmd.
NSM: Minor GUI enhancements.
NSM: Don't forget to inform GUI of the removal of stopped
clients when closing a session.
OSC: Fix signal creation notification.
Cleanup compiler warnings.
NSM: Time client responses.
Update documentation.
Mixer: Document spatialization control for Ambisonics plugins.
Mixer: Update documentation.
scripts: Allow suggested packages.
Everybody gets new icons! Also, .desktop files.
Use getopt_long for processing command line arguments to Non-DAW
and Non-Mixer.
NSM: For lack of a better place to put it, add 'jackpatch'
program to the repository.
NSM: Minor cleanup.
NSM: Update documentation.
Add notes to packagers.
Add 'gleam' inspired boxtypes to replace the ones in the gtk+
theme. Also, tweak crystal boxtypes.
Mixer: Add new 'plastic' knob type. Make knob type to display
configurable.
GUI tweaks.
Mixer: Try harder to avoid drawing meters more than necessary.
Timeline: Work around bug in FLTK 1.3 when drawing a string
containing only symbols.
Mixer: Make slider types optional too.
Timeline: Warn about buggy FLTK version.
Mixer: Try to fix some weirdness with Controller Module knob display.
Mixer: Implement mixer Strip import/export
Update Non-DAW screenshot in documentation.
Bump versions.
Thanks, sounds good, I am thinking here: cheap synthesizer.
Victor
On 29 Feb 2012, at 10:40, James Harrison wrote:
> Comes with a DAC, but no ADC as far as I can see.
>
> Cheers,
> James Harrison
>
>
> On 29/02/2012 10:30, Victor Lazzarini wrote:
>> Does anyone know whether the Raspberry PI comes with a DAC/ADC?
>>
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>>
>>
>>
>> _______________________________________________
>> Linux-audio-dev mailing list
>> Linux-audio-dev(a)lists.linuxaudio.org
>> http://lists.linuxaudio.org/listinfo/linux-audio-dev
Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
Hi everyone, hoping to get opinions from gurus on here, who have been
*incredibly* helpful in getting my project to where its at. A million thank
yous!
Ok, the situation so far, which is working well:
- the app uses a generalized 'message' structure, all the different forms
of messages fit into this structure by having it act alike a union. ( ie, a
message always takes up the same amount of space, no matter the type )
- messages do not container pointers, in order that they be simple to send
and receive over network clients, hardware, etc
- there are ringbuffers between my audio thread and real time thread
What I'm tackling:
- I want to add the capability for messages to have deferred execution, so
they can be sent with a 'process at 4:3:1' kind of thing
- I think the best tradeoff for my app so far will be to use a hybrid of a
timeline array and a linked list. there will be coarse time values stored
by raw array indexing, speeding up lookup, and fine time values will be
stored in the messages themselves
- so, when the engine is processing deferred messages, it will go and check
timelineArray for all messages at bar 1:beat 1, which will be a linked list
of all the messages with start time between bar:1 beat 1 and bar 1: beat 2
( time resolution may change, this just for example
- then the engine iterates on every tick through that list of messages.
This way, iteration on every tick is limited to a reasonable sized linked
list and I can play with the cpu vs data storage equation by simply
changing the resolution of the time line array
Issues:
- I need to allocate memory for new linked list items in the realtime thread
- the timeline array needs to be able to grow in the real time thread
Thoughts:
- I don't need to get it perfect *right now* but I need to be able to
change it to Really Good later
- I checked out some resources, like this one the Design Patterns for *Real*
-*Time* Computer *Music*
Systems<http://www.google.ca/url?sa=t&rct=j&q=audio%20allocating%20memory%20in%20re…>
and the supercollider book chapter and see there are a lot of options
- I could pre-allocate a giant list of messages and pluck the data off that
list when I need to make a new one
- I could pre-allocate a block of memory and allocate off that
- I could allocate in the non-realtime thread and then pass memory over in
queues.
Would love to hear opinions on how others would solve these, including
tradeoffs of each.
thanks!
iain
Hello list,
I would like to share a piece I've just finished.
The original blog entry is here, but for your convenience I'll include a copy into this mail.
Feel free to use any channel you want if you would like to comment on it.
http://www.nilsgey.de/2012/02/29/airship-theme/
Airship - A 16bit Soundtrack Theme
direct download: http://www.nilsgey.de/uploads/NilsGey-AirshipTheme.mp3
I have finished my first just-for-fun composition since a very long time ago. It is a game-soundtrack like piece I named “Airship”. I can imagine this in a Japanese 90’s RPG from the SNES or Sega Genesis/MegaDrive era.
Software used: Laborejo composition and midi generation, Fluidsynth for midi to wave rendering and Ardour for the fadeout :) .
I used an .sf2 called Setzers SPC which I have downloaded here. I am not sure about the soundfonts legal status so I am careful and release the Airship Theme not as a free piece but just as: Listen to it freely, share and redistribute it but don’t use it in any work, derived or original, or as part of a game or video etc. Don’t do anything commercial with it and don’t change the mp3 tags. If you find a named, matching License to this description feel free to use that instead.
I would be very happy if you leave a comment or click this blogs “Like” button.
Greetings,
Nils
http://www.nilsgey.dehttp://www.laborejo.org
If there is Linux and Alsa, we should just be able to cross-compile (or even compile on the Raspberry if there is gcc); I don't see many difficulties. It should be easier than android and iOS.
I might see if I can get one to run Csound on.
Regards
Victor
On 29 Feb 2012, at 10:46, James Harrison wrote:
> I'm hoping that adding an ADC won't be too tricky, though it has USB so a USB sound card should work. For $25 an end, it'd make a lovely portable IP codec for broadcast with CELT and RTP...
>
> Cheap synth would be neat, though. Wonder how much stuff in the Linux audio world is ARM-compatible?
>
> Cheers,
> James Harrison
>
>
> On 29/02/2012 10:45, Victor Lazzarini wrote:
>> Thanks, sounds good, I am thinking here: cheap synthesizer.
>>
>> Victor
>> On 29 Feb 2012, at 10:40, James Harrison wrote:
>>
>>> Comes with a DAC, but no ADC as far as I can see.
>>>
>>> Cheers,
>>> James Harrison
>>>
>>>
>>> On 29/02/2012 10:30, Victor Lazzarini wrote:
>>>> Does anyone know whether the Raspberry PI comes with a DAC/ADC?
>>>>
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> Dept. of Music
>>>> NUI Maynooth Ireland
>>>> tel.: +353 1 708 3545
>>>> Victor dot Lazzarini AT nuim dot ie
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Linux-audio-dev mailing list
>>>> Linux-audio-dev(a)lists.linuxaudio.org
>>>> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>>
>>
>>
>> _______________________________________________
>> Linux-audio-dev mailing list
>> Linux-audio-dev(a)lists.linuxaudio.org
>> http://lists.linuxaudio.org/listinfo/linux-audio-dev
Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
Does anyone know whether the Raspberry PI comes with a DAC/ADC?
Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
Here's another video, this one demonstrating the fact that NSM can
manage a single session with clients spread across multiple machines
(nsmd must be running on each system).
http://youtu.be/xzspJXbEoc0
I forgot to show that when you add a client via the GUI, it asks you
which server to start it on. Otherwise, the behavior is identical to
having a session on a single machine. If you just start up an NSM
capable client on any of the machines participating in the session
(with the appropriate environment variable set), then that client will
join the session as normal.
This distributed session feature is just a natural consequence of the
architecture of NSM and doesn't add any complexity to either the
client or server implementation (just a small amount to the session
manager GUI).
I'm getting pretty close to doing the release, but I still have a lot
of documentation to write and update for the user interface changes.
Enjoy!
Greetings,
I notice that whenever I use any Juce-based native Linux VST plugin - fx
or instrument - in Ardour3 the plugin produces dramatically more xruns
than any LV2 or LADSPA plug. Does anyone else have that problem ? If so,
can anything be done about it, apart from raising my latency settings ?
Thanks,
dp
Sometimes, I wonder why I even bother... First, recordmydesktop didn't
work, so I had to film the screen with a video camera, then ffmpeg2theora
took ages to transcode the video from MJPEG and added some annoying clicks
to the audio track, then the new archive.org uploader didn't work, so I was
stuck with using youtube.com, which refuses to display the video in HD.
Alas, I am to learn again and again that the only way to have things done
right is to do them yourself. On that note, I'd like to introduce to the
wider audience a project that I started shortly after writing this:
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2008-May/021084.html
... post to the LAD list back in 2008. Well, I haven't been very active
since then--well, such is life--but in the past couple of weeks I've spent
some time developing the idea and I'd like to demonstrate it in the
following video:
http://www.youtube.com/watch?v=ui-gC_ZMeGM
I'll be pushing my changes in the next week or two along with some other
fixes and enhancements to the Non-* family. Those who have been following
on #lad may have already seen draft versions of the NSM API. The final
draft (version 1.0) will be posted to the LAD list soon also.
Robust audio session management on Linux is now a solved problem. You're
welcome ;-)
Enjoy!
