Hello everyone,
Today I released the version 0.0.7 of the ams.lv2 plugins.
What was done in this version:
* The License file is updated
* Ported from AMS:
- Absolute
- Inv
* A new LFO based on the AMS one, but can be synced with Jack
* A beat repeater:
~ ported from Tranches (http://hitmuri.net/tardigrade/index.php/En/News)
~ Synced with Jack
* URI modified to http://avwlv2.sourceforge.net
The beat repeater code is a bit raw, it works but it uses a lot of CPU
cycles - more than I would like!
As usual, comments, feedback and testing are more than welcome!
My next step is to use the CV ports from LV2.
Enjoy!
Aurélien
ChipSound 0.1.0 under zlib license
----------------------------------
"I’ve decided to officially release the engines
(scripting, physics, sound and 2.5D rendering)
behind Kobo II as Free/Open Source, in order to
make the game available to basically anyone with
OpenGL and a C compiler.
[...]
First out is ChipSound, which is now under the
zlib license.
[...]"
NOTE:
ChipSound currently depends on SDL for audio I/O.
Full story:
http://olofsonarcade.com/2012/03/13/chipsound-0-1-0-released-zlib-
license/
Direct download:
http://www.olofson.net/download/ChipSound-0.1.0.tar.bz2
Related; Kobo II site:
http://kobo2.net/
--
//David Olofson - Consultant, Developer, Artist, Open Source Advocate
.--- Games, examples, libraries, scripting, sound, music, graphics ---.
| http://consulting.olofson.nethttp://olofsonarcade.com |
'---------------------------------------------------------------------'
Hello all,
Does anyone know of a way to monitor or poll Ardour's (global)
'record-armed' and/or 'recording' states from the outside ?
The purpose is to control a 'recording' light in the studio.
Ciao,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
Emanuel Rumpf:
>
> Am 8. M?rz 2012 01:08 schrieb <kallipygos(a)inbox.lv>:
>>
>> It is possible with (curses-ansi escapes) TUI vary sine parameters -
>> Frequency and amplitude.
>>
> Possible with restrictions:
> You cannot call blocking functions in jacks process() function.
> Thus non-blocking inter-thread communication may be necessary.
>
>>
>> Is it possible this program __as_is__ rewrite for jack output ?
>>
>
> Jack Audio uses a _callback_ based api.
> What you have there is not.
>
> You could re-use the above code with simple adjustments
> by adding an additional bridging library.
> (Eventually causing loss of realtime capabilities.)
>
> Look at :
>
> bio2jack -- http://bio2jack.sourceforge.net/
>
Shouldn't be used. bio2jack both allocates memory and locks a mutex in
the process callback.
(yes, it still does, look at the code on sourceforge)
> jackasyn --
>
> http://packages.debian.org/search?suite=default§ion=all&arch=any&search…
> (I couldn't find its original home)
Good advice. jackasyn is made properly.
I want to learn how to program with JACK. I found this tutorial:
http://dis-dot-dat.net/index.cgi?item=/jacktuts/starting/
linked from this page ( http://jackaudio.org/documentation ). I noticed
that the tutorial has some broken links. Is this still a good resource to
learn from? Or are there any better ones out there? Any suggestions will
be much appreciated.
Thanks,
Kris
Laborejo, Esperanto for "Workshop", is used to craft music through notation.
It is a Lilypond GUI frontend, a MIDI creator and finally a tool collection to inspire and help you compose.
It works by reducing music-redundancy and by seperating layout and data. Don't worry about the layout, just concentrate on the music.
Screenshot (Laborejo and Lilypond, side by side): http://www.laborejo.org/images/screenshots/2012-01-31-223820_3840x1080_scro…
This is the first release, version number 0.1
Download: https://github.com/nilsgey/Laborejo/tarball/0.1
Dependencies: http://www.laborejo.org/documentation
There are too many features to mention them all and too many missing features and bugs to warn you. Most important known problems:
* This is Alpha Grade Software. Don't use for long-term work. However, the produced midis and PDFs will last forever.
* Performance can get bad very quickly if you use Containers.
* There is no built-in sophisticated midi player/jack midi output yet. You have to export midi files.
* Documentation is nearly non-existent.
Have fun, it would be nice to hear from you!
Nils
http://www.laborejo.org
(All kinds of crazy social web services are linked there!)
Howdy,
There's no victory over anything whatsoever. Read it again, it's just a
codename. If that serves anything at all, to my own defense that is,
Qtractor is still a pet project hobby of mine, as all things in Linux
audio world for that matter.
There's been too many saying and comparing Ardour vs. Qtractor. I'm
seeing if often said in too many sentences lately and, believe me, I
cannot stand comfortable with that saying no more.
So here it goes: Ardour is a full fledged, pro-level DAW and, for crying
out loud on its own, the flagship of the free/open-source pro-audio
fleet and movement, not only Linux anymore nowadays. On the other hand,
Qtractor is 'a sequencer' (hinted by its own subtitle, in case you
didn't notice) with a twist and a few of a DAW features. And it strictly
runs on the Linux platform only and most important yet, it has been
targeted to a (re)creational personal home-studio audience ever since.
Heard about the 'techno-boy bedroom' (with a guitar) folk? Well, that's
exactly what it is, from day zero. Hope you all get the picture ;)
Enough whining.
Qtractor 0.5.4 (echo victor) is out and is shouting out loud!
Release highlights:
* Panic command button (NEW)
* Improved audio/MIDI file resource management (NEW)
* MIDI SysEx for instrument plugins (NEW)
* MIDI Controller auto-hook option (NEW)
* MIDI Tools resize ramp (NEW)
* Revised plugin search directory paths (FIX)
* MIDI zero-duration note-on/off queueing (FIX)
* Audio linked-clips looping (FIX)
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
- source tarball:
http://downloads.sourceforge.net/qtractor/qtractor-0.5.4.tar.gz
- source package (openSUSE 12.1):
http://downloads.sourceforge.net/qtractor/qtractor-0.5.4-3.rncbc.suse121.sr…
- binary packages (openSUSE 12.1):
http://downloads.sourceforge.net/qtractor/qtractor-0.5.4-3.rncbc.suse121.i5…http://downloads.sourceforge.net/qtractor/qtractor-0.5.4-3.rncbc.suse121.x8…
- long time ago, far far away: user manual:
http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf
Weblog (upstream support):
http://www.rncbc.org
License:
Qtractor is free, open-source software, distributed under the terms
of the GNU General Public License (GPL) version 2 or later.
Change-log:
- Direct access plugin/insert parameter changing tool-tip added.
- A Transport/Panic action enters the scene, in a nostalgic attempt to
emulate the all-MIDI-track-shut-off command of those drop-dead and
primordial MIDI sequencers of all time. Now finally a keyboard shortcut
and mouse click-away ;)
- MIDI editor command redo/undo adjustment now effective on all other
channel events besides notes, which overlap at the same event time.
- A new File/Unlink menu action is now made available from the MIDI clip
editor (aka. piano-roll) for detaching the current linked/ref-counted
MIDI clip into a new auto-incremented SMF filename.
- Some audio/MIDI content/media-file resource management is entering the
scene, taking care of some file-system house-keeping, this gets evident
on unsaved/dead recorded files being automaticaly removed from the
file-system, on session close.
- Killed the old and entirely deprecated LV2 Save/Restore and Persist
feature/extensions support.
- Auto-monitored MIDI events are now merged/queued correctly into the
instrument plugin playback queue, avoiding sudden crashes, hopefully.
- Awesome patch from Albert Graef, thanks, which makes most MIDI SysEx
to get through MIDI instrument plugins at last; applies to DSSI and LV2
plugins only.
- LV2 URID map/unmap feature support added.
- Plugin parameter value redo/undo command aliasing fix.
- Double-clicking in plugin list item now show/activates the plugin's
editor window (was toggling visibility/activation).
- Plugin path settings have been fixed again, with special regards to an
effective LV2_PATH environment variable settlement.
- Session properties dialog now asks to create a new session directory
if the given one does not currently exist.
- MIDI note names and their respective octave numbers are now compliant
with the ISO standard where middle C (60) is now C4 (was C3).
- Fixed audible glitch/pop at the beginning of an audio clip with long
quadratic or cubic shaped fade-in (reported by Lougi Verona, thanks).
- MIDI Controller Auto-Hook patch by Alessandro Preziosi, thanks.
- Make sure all MIDI note-off are always queued after their respective
note-on events when buffering for MIDI input of instrument plugins,
event though for zero duration MIDI note events (hopefully fixing the
hanging notes bug #3476124, as reported by Albert Graef, thanks).
- LV2 MIDI-fx plugin support has been repaired.
- Single-track clip selection logic corrected again, fixing multi-clip
selection drag/move across an odd number of distinct tracks (after a bug
report by Louigi Verona, on linux-audio-dev, thanks).
- MMC Locate time-code hour bit-field fix; MMC Locate now also on loop
turnarounds (patches by Albert Graef, thanks).
- Looping across multiple linked/ref-counted audio clips was incredibly
broken with complete out-of-sync playback. Hopefully fixed now, with
auto-unlinking/cloning all the affected audio clip buffers.
- Audio clip overlapping detection off-by-one(-frame) fix.
- MIDI Tools/Resize value ramp mode has been added (mocking the 'resize
to range' feature request #3467894, by Daniel MacDonald aka. danboid).
Enjoy && Have fun!
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
2012/2/29 Kevin Thoma <kevin.thoma88(a)gmail.com>
> Hi there,
>
> really liking the piece, great job! And having just played one of those
> RPGs for the first time in ages (and I do remember them from my childhood
> days as well...), I can attest to the fact that it would them nicely. ;)
> I agree that taking the drums out for one of the quieter parts would have
> made for some nice contrast, but yeah, that's not a must.
>
> Best Wishes
> Kevin
>
>
> On Wed, Feb 29, 2012 at 6:30 PM, Nils <list(a)nilsgey.de> wrote:
>
>> 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.de
>> http://www.laborejo.org
>> _______________________________________________
>> Linux-audio-user mailing list
>> Linux-audio-user(a)lists.linuxaudio.org
>> http://lists.linuxaudio.org/listinfo/linux-audio-user
>>
>
>
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user
>
>
Hi,
I concur with some said already; it reminds a bit of some soundtrack for a
game and maybe, at 1:00 min and at 4:30 aprox., would be nice to have a
quiet part as a middle section to rise then up as an anthem.
Also would be advisable some processing (Delay, Reverb) on the mix to make
the sound a more realistic, to mitigate the rude MIDI sound, and as if
recorded in some space, a large hall i.e.
Nice music,
Thanks for sharing, Nils
--
Carlos sanchiavedraz
* Musix GNU+Linux
http://www.musix.es
Georg Holzmann wrote:
> Hallo!
>
> > The only real problem I've had doing it is finding time to work
> > on it. Fortunately I am pretty sure I will find time to work on
> > this between xmas and new year.
>
> Thanks for the answer!
> If you need any testing or something else let me know!
Hi Georg,
Support for 16 bit ALAC is in Git at:
https://github.com/erikd/libsndfile
Support for other bit widths will be added in the near future once
I know the 16 bit stuff is working.
Cheers,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
It seems this debate is how to represent OSC messages in a sequencer.
I've thought about this before, and the idea I always had in my head
was something tracker-like, where you would assign columns (or rows..)
to a message path, and specify whether the arguments are ints, floats,
etc. For each argument the column would contain subcolumns with
fields allowing editing of these values. Any row that is all "nil"
would mean "do not send a message."
The editor might allow a special column type called "note" which is
represented on-screen as a note name (A#3 or whatever) but sends out
the value as an integer or float.
Alternatively the editor could be told the min/max values of the
subcolumn and represent it as horizontal bars or a line plot, etc.
I even started working on such a thing once, with the intention of
controlling sequences for custom synths written in e.g. Chuck or
PureData. However, I never got far with it as I had other things to
do.
In any case, in this paradigm, the user would define a patch in Pd
(or....) which accepts certain control or trigger messages, and
therefore the sequencer would need to be told what messages to send
it. No need to "standardize" the messages for any particular
representation, since it would be different for each patch anyways.
(The "sequence + patch" would be considered together as the music
file.)
What I like about this is that it would allow a user to use whatever
program he/she wants for sound synthesis, but have keep a consistent
sequencer interface. You could even use multiple back-ends for sound
synthesis in the same track.
p.s. thanks Jonathan for bringing up libmapper. For those who don't
know, libmapper is an attempt to create a "glue" layer for
OSC-supporting programs. Instead of standardizing on a set of
messages, the idea is to instruct sending programs to translate their
messages into the format required by the receiver, including any data
transformation (scaling, etc). This allows programs to use any
message names they want, keeping the usefulness of readable,
program-specific semantic naming schemes, while still being able to
connect to each other. Still under heavy development, but it's quite
functional, web site is at http://libmapper.org
Steve
On Sun, Mar 4, 2012 at 4:27 PM, Albert Graef <Dr.Graef(a)t-online.de> wrote:
> On 03/04/2012 06:32 PM, David Robillard wrote:
>>
>> What do you mean by "pick the OSC addresses that I want"?
>
>
> I mean those symbols with the slashes that are the first part of any atomic
> OSC message like /foo/bar 4711.0. Usually such a symbol would denote the
> particular control that the value applies to. When using OSC as input to or
> output from automation, obviously I'd have to specify which OSC addresses I
> want to be mapped to which automation parameter.
>
> However, I'd actually prefer a kind of separate OSC track which would be
> connected to OSC inputs and outputs and listens for all OSC messages on its
> OSC inputs, no matter what the addresses are. So (an ASCII representation
> of) the contents of such a track might look like
>
> # delta OSC addr value
> 0 /foo/bar 0.78
> 10 /reverb1/wet 0.3
> 5 /foo/bar 0.66
> etc. etc.
>
> By these means the OSC track would just record any messages that it receives
> on its inputs, and I might then map them to the appropriate automation
> parameters on other (audio and MIDI) tracks in the DAW, or just have them
> played back via the OSC outputs assigned to the track, in order to drive
> some other application like Pd.
>
> Dave, will you be at LAC in April? I'd really like to discuss this in more
> detail with you, but it's much easier to do this in a room together and with
> a whiteboard and a data projector within reach. ;-) If there's enough
> interest, maybe we could do a "control beyond midi" brainstorming session at
> LAC? Maybe Rui wants to join us there, and I know that some guys at CCRMA
> are also interested in this. I guess that the organizers can allocate us a
> time slot and a room with the necessary equipment if we just ask for it.
>
> Albert
>
> P.S.: Rui, apologies for hitchhiking your thread. I hope that you will
> forgive me over a glass of good Californian wine. ;-)
>
>
> --
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
> Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
> WWW: http://www.musikinformatik.uni-mainz.de/ag
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev