Hi All,
Just thought I'd mention that my software blue
(http://www.csounds.com/stevenyi/blue) supports tuning systems with a
microtonal piano roll that reads in Scala
files(http://csounds.com/stevenyi/blue/blueDocs/html/pianoRoll.html),
and is somewhat like a sequencer application (mixing of SCO fragments,
SCO generation scripts in python and javascript, etc.). It's built for
use with csound and is GPL. Although I'm not sure if blue is in the
same vein as what the original poster of this thread is looking to
build, I thought it might be something worth checking out, perhaps
simply for ideas on possible ways to implement (or not to implement) a
solution.
Also, I know that newer versions of Apple's Logic sequencer do support a
limited degree of alternate tunings (can not find info on it on Apple's
site at the moment).
steven
>Alfons Adriaensen wrote:
>
>
>
>>On Tue, May 03, 2005 at 08:36:29AM -0400, Dave Phillips wrote:
>>
>>
>>
>>
>>
>>>Considering its suitability for microtonality, why not design
>>>something around Csound ?
>>>
>>>
>>>
>>>
>>>From the origianl post:
>>
>>
>>
>>
>>
>>>The problem is that I don't know of any software synthesizer that is:
>>>
>>>1. good enough for decent music production;
>>>
>>>
>>>
>Well, Csound is being used for just that purpose. Perhaps the original
>poster should check out recent traffic on the Csound mail lists.
>
>
>
>>>2. easy to use by non-experts (this is a direct stab at CSound, or
>>> better at its lack of a decent GUI, of a standard instrument exchange
>>> file format and of a decent, centalized library of presets)
>>>
>>>
>>>
>Csound has no integral GUI, sorry. It does have a set of FLTK-based GUI
>widgets which lets you create your own GUI.
>
>The Csound orc file has been and still is the way Csounders exchange
>instruments. There are in fact a number of instrument libraries out
>there. I think the original poster might not be quite up to date on Csound.
>
>
>
>>>3. free software.
>>>
>>>
>>>
>>>
>Csound is LGPL and has been for some time now.
>
>
>
>>To add my 0.02 Euro : I'm sure that OSC is the way to go for this project.
>>And I'd love to have an 'OSC sequencer' -- something that allows you to
>>schedule / edit / manipulate arbitrary OSC events, and with a non-destructive
>>region editor similar to Ardour's.
>>
>>
>>
>>
>Sounds cool, I'd like to see that too.
>
>Btw, Rocky was a project with somewhat similar goals, a sequencer for
>22-tone ET, using Csound for its rendering engine and Java for its GUI.
>Alas, Rocky appears to have disappeared. [Insert obligatory Sylvester
>Stallone joke here].
>
>Best,
>
>dp
>
>
>
>From: Jens M Andreasen <jens.andreasen(a)chello.se>
>
>Is it gtk then? Or the pixmap engine?
I don't use pixmap decorations in my application, but
only one pixmap of size 800x600 was too slow. I used
the preferred pixmap functions of GTK2. The expose of
the whole 800x600 pixmap took 120 ms (8 fps). That was
impractical.
Then I switched to gtkglext which in my system apparently
uses Mesa with software renderer. (How to verify it?)
Now the system is fast. One app renders 3D objects and another
app draws 2D objects (http://www.funet.fi/~kouhia/enved7.png).
I would like to know if gtkglext in my system uses Mesa and
if Mesa uses software renderer. How that can be tested?
What I would like to have would be vertex and fragment
shaders for audio widgets. E.g., a 2D or 3D knob would
rotate with vertex shaders. E.g., a level meter a la
SoundForge would have a fragment shader dimming the top of
the black-green-yellow-red texture map based on the meter
value.
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
Could you please remove me from your mailing list as I will be away
from email for an extend period of time.
I'm David Wessel at wessel(a)cnmat.berkeley.edu
Thank you,
David Wessel
Hi!
As you might know, the initial phase relation between oscillators in an
FM synth is quite important for the resulting sound. Not least when you
are dealing with feedback loops.
I have had velocity sensitivity on phase for ages, but came to think of
that keyfollow on phase might be more useful? The rationale being that
adjecent notes would then have slightly different harmonic series (or
dramatically different, depending on other settings.)
One advantage would be that "clean" sounds (ie: Piano) could have some
unique harmonic space surrounding each note, so that blockchords can
live harmonically together in an even-tempered world, without too much
beating and without resorting to detuning, PWM and whatnot.
So I made this new button near the other phase parameters, added a few
lines of code and prepared a test patch called "Test III" located in
"H.4" (which at least to my ears and speakers is partially reminiscent
of a piano.)
The new button switches between phase-velocity or -keyfollow for the
slider just below.
What?
Oh ... Here:
http://hem.passagen.se/ja_linux
(no new screenshot)
--
(
)
c[] // Jens M Andreasen
About 3 years ago there was a thread here about using Chebyshev
polynomials to mimic guitar amps -- I think I have found at least
a partial solution to some of the problems mentioned at that
time -- could someone send me the amplifier characteristics they
were trying to reproduce, or any other tests? Thanks!
Hi!
I have been thinking about how an advanced sequencer could
look and work over and over again and now finaly managed
to come up with one consistent concept that i would like
to present here now.
A mockup to illustrate the following explainations:
http://wrstud.uni-wuppertal.de/~ka0394/forum/sequencer_05.png
The basic idea is to have nested containers to be arranged
verticaly and horizontaly. All information is tied to or
contained in these containers.
As the horizontal axis stands for time, i needed to express
the nesting only verticaly (plus color), so that's what the
round corners and the empty bottoms of the containers are
for. Maybe it helps when you think on Lisp and paranthesis,
only vertcaly.
On the mockup the big white container defines absolute
time (min/sec) and the context for playback control (only
one play position inside thsi container (for each user)).
Several of them could exist in parallel, all with their
own playback control.
The next, yellow container defines the meter (the ruler)
4/4, followed by a tempo track set to 120 BPM.
The blue container is an audio container. These can
take others of their kind, audio inputs and outputs
and finaly audio clips. This one defines an "Out 1"
and its send level and conatins 3 clips.
Below it, the green container sets a 3/4 meter.
Because it is inside the 4/4 container, the quarter notes
match. If outside, it would have to have its own and
independent tempo track.
The last Container is for MIDI. It has IN and OUT as
attributes. Alternatively these could be expressed on tracks
like used for tempo, what would make them changeable inside
the container.
Every Container can be used as a pattern (instances).
They could have a dropdown menu to swutch between
different versions (/takes).
I have some more ideas and details, but i think this should be
enough for now! :)
I have only basic and seldomly applied coding skills, and
this doesn't look like a one man project anyway ...
So I hope for interested developers ... or that at least
this gives someone some inspiration. I would be happy to
further develop my concepts of course (allthough my diploma
in industrial design, same topic: sequencer takes priortiy
for the next 3 months).
---
Thorsten Wilms
Hi all,
I would like to know if someone knows if the Evolutif Audio
( http://evolutif.sourceforge.net/ ) project is alive (no CVS, no releases
from 2003). If not, is there any other similar audio project actually in
running?
I'm thinking to extend this code stuff (Evolutif) and I would like to parse
possibilities and efforts.
Thanks,
--
J_Zar
Gianluca Romanin
----------------
See you at OpenJay.org
>From: Simon Jenkins <sjenkins(a)blueyonder.co.uk>
>
>2. Is C++ OK? (You'd end up with a Patch class that could be
>over-ridden to dump itself in whatever format was required).
C++ is ok, and would make sense because the nmedit code is C++.
For each module, the nmedit has a parameter etc. descriptions.
If I understand correctly, we don't need them because we write
our modules as an exact clones (inputs, outputs, parameters at
least). But if the nmedit code already loads all the information,
please keep it that way. The info could be useful.
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
by Kjetil Svalastog Matheussen <k.s.matheussenï¼ notam02.no>
Thorsten Wilms:
>As the horizontal axis stands for time, i needed to express
>the nesting only verticaly (plus color), so that's what the
>round corners and the empty bottoms of the containers are
>for. Maybe it helps when you think on Lisp and paranthesis,
>only vertcaly.
Below is my (short) personal view on your design. Don't
take it as an attack on your ideas, but a different persons
opinion, and use it for what its worth.
I think this kind of design of a graphical
interface for western classical scores on a computer
is inefficient because it wastes too much space on the
computer screen. The result is that the composer needs to spend work
doing too much navigation.
Whats the point of visualy seeing the pitch of notes? You hear
them much better. Just write the name of the notes instead of
spending all that much vertical space.
I spent three years coming up with this design:
http://www.notam02.no/radium/
which I know (by personal experience) is a damn extreme
efficient note/score editor.
http://www.notam02.no/~kjetism/radium/pictures/v062_linux.png (linux
screenshot)
http://www.notam02.no/arkiv/src/radium-0.63.tar.bz2 (linux alpha)
Greetings all,
First off, apologies for cross-posting...
I would just like to share the quick-and-dirty downmix of the premiere of my
latest work "Symmetries" (that took place at the last-week's "Linux Audio
Conference" in Karlsruhe, Germany) with the LAU/LAD as well as Pd community.
Without you guys, this piece would never have been possible :-).
As my token of gratitude, in conjunction with this release I am also
releasing the soundfont that I've built from scratch using exclusively Linux
software (Swami, Rezound) and specifically for use in this piece. For more
info on each of these please see notes below.
As always, your feedback is much appreciated!
-------------------
About "Symmetries:"
Symmetries (for computer and optional violin) is an experiment in relegating
musical structure and expression to the inherently stupid box of
transistors. By concurrently utilizing various GNU/Linux audio software
(Fluidsynth/QSynth, Pd, LADSPA, Jack-rack, JACK) it was composer's intention
to generate a lush interactive texture whose frail balance engenders a
consistent forward drive. In an ever-changing array of hierarchical
probabilities no two instances are expected to ever be the same. The piece
has been designed to be completely modular in terms of computer-driven sound
diffusion and can utilize 2-8 channels.
For its premiere the piece used 8-channel diffusion. However, the recordings
below are provided in a stereo-downmix form.
Hardware used in performance was eMachines m6807 laptop (64-bit AMD 3000+),
RME HDSP Multiface, and a Peavey 1600x midi controller that I used to
control some of the timbral nuances via Pd and Jack-Rack (LADSPA).
The violin part was played by Ania Zielinska (Poland) who commissioned the
work.
-------------------
There are 3 recordings available:
1) 128-bit (fixed rate) 48KHz OGG recording of the premiere:
http://meowing.ccm.uc.edu/~ico/Symmetries_LAC_2005_premiere.ogg (5.8MB)
2) 128-bit 48KHz MP3 recording of the premiere:
http://meowing.ccm.uc.edu/~ico/Symmetries_LAC_2005_premiere.mp3 (6.0MB)
3) 64-bit 44KHz MP3 of the computer part:
http://meowing.ccm.uc.edu/~ico/Symmetries.mp3 (2.8MB)
-------------------
The soundfont is a based on series of recordings of solo violin playing
straight tone "con sordino" sound. The recordings have been structured in a
gigasampler fashion (minor 3rd apart, except for the open strings). It has 2
sets of samples, ones without limiter which have already been mapped, and
other with the limiter which are in the soundfont but have not been mapped.
The sample tuning has been adjusted "by ear," so it may not be
mathematically accurate but FWIW it did pass my own scrutiny (which should
be taken with a grain of salt as this piece is not as demanding when it
comes to absolute preciseness of the tuning of individual pitches). The
looping of sounds is measured to provide most seamless transition while
accounting for the change of the direction of the bow. Conceivably one could
create a sense of orchestral sordino by layering the same sound over and
over. The soundfont does have reverb and chorus abilities enabled but IMHO
it sounds the best without any chorus applied to it.
The soundfont is released under the "GPL/Artistic 2.0" license (for more
info please see: http://dev.perl.org/perl6/rfc/346.html). Btw, I chose the
art-related license simply based on my limited understanding that it is more
appropriately tailored towards something that is not code-based. That being
said, if anyone can explain me the difference between the two licenses, I
would really appreciate it :-).
To download the soundfont please click here:
http://meowing.ccm.uc.edu/~ico/Linux/violin_sordino.tar.bz2 (21.5MB)
NB: Considering that the Linux server that is hosting this may be on its
last legs (strange noises from the HD), I would not mind if someone would
consider mirroring this particular file. Many thanks!
-------------------
Once again, I would like to extend my thanks to the developers and users
alike of the open-source, and perhaps more importantly, Linux audio
software!
Many thanks also go to the organizers of the Linux Audio Conference for
making this performance possible!
Best wishes,
Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/