Hi Veli-Pekka.
Wow, this is a very informative and interesting post.
I don't have nearly the experience you do with synths, especially software
ones. I've used a couple hardware modules, but have no front panel access so
can't really tweak much.
I do think our goals are similar. I don't know how reactor or nord or
whatever work. I do have a vague sort of abstract sense of what I want the
software to feel like... I basically am a tweaker, not necessarily a
programmer, although I have done a bit of programming in my time.
at a practical level, putting together modules, binding hardware knobs to
synth parameters, saving
presets and playing the whole thing via MIDI in real time.
Yes, this is what I'm aiming for myself.
I invision a system with some standard set of virtual instruments coded in
ChucK. Each instrument would live in its own file, which could get
displayed in a listbox in the UI. When a file was loaded in the UI, it would
just call ChucK on it to load it into its VM and start it running in
paralell with all the other currently running instruments. The UI would
maintain a list of currently running instruments, and navigating this list
would allow you to set parameters for that instrument, including ins and
outs.
The instruments could be implemented as stand alone ChucK programs. When
run, each program would open a OSC connection and then wait for control
messages from the UI. These messages would either be requests for state and
available parameter data, or commands to modify the state of a parameter.
You could have some sort of mechanism that allowed each ChucK module to tell
the UI what parameters it has available for tweaking. The UI would be
responsible for keeping track of what parameters were available for each
module, and allow you to set/change any of them on the fly.
ChucK has many types of unit generators and has filters and basic effects
like reverb already in its standard object library.
there are very few analogs of the basic Reaktor building bloks at the
module level, the idea is that you program them in on an ad hoc basis,
Can you describe a bit more about what a reactor module might look like?
Again, it seems that ChucK has a lot of the basic building blicks available.
We'd need to come up with an architecture to tie the gui to chuck, and then
come up with a standard module or instrument class which would then make the
writing of each real instrument more straightforward since it would take
care of the parameter handling etc.
We could start off with one basic single sample instrument, and one
acoustically modeled instrument. I can invision eventually having some sort
of SFZ parser which could read .sfz instrument files and then spit out
equivalent ChucK code based on the same sample data. SInce .sfz files are
simple text files, and the samples come separately, this might not be so
hard.
very big job and something I'm not up to yet. However, this might work
well as a collaborative project, if the scope was narrowed to very early
releases and an essential subset of the modules. The only thing I've
emulated so
far is the audio switch, with a parameterizable number of inputs, if I
recall correctly.
Can you say a bit more about this audio switch? Is this in ChucK? Did it
have a gui or was it midi controlable, etc?
Hope this makes sense... Maybe I'm getting too low-level here...
-- Rich
----- Original Message -----
From: "Veli-Pekka Tätilä"
To: "ChucK Users Mailing List"
Sent: Monday, November 19, 2007 7:07 PM
Subject: Re: [chuck-users] Controling Chuck - building accessible GUI
Hi Rich,
I'm a fellow legally blind screen reader and magnifier user interested
in ChucK running Win XP and the Dolphin Supernova reader & magnifier. I
think our goals are actually quite similar. Although I must confess I
haven't done much with ChucK lately. In addition to the cool, domain
specific programming language it has, one of the big ideas intriguing me
is the ability to use a modular synth independently. Needless to say
I've never really used hardware modulars but did use Generator and
reaktor before they went with portable and inaccessible custom controls
and forgot both the keyboard interface and the user's color scheme. In
the end, despite being a programmer, too, my goal is to do music rather
than pure sound design or DSP so I would like to keep things practical.
Nord Micro Modular is something that I'll have to look into, however I
suppose the editor just is not accessible, at least the G2 demo release
is not.
So my thought was since I cannot use Reaktor, I would like to be able to
achieve the equivalent thing somehow, at a practical level, putting
together modules, binding hardware knobs to synth parameters, saving
presets and playing the whole thing via MIDI in real time. In that
context ChucK was not LInux only, was more real time than C Sound
apparently and had a nice, easy programming language for the job.
So far I am very far from realizing this Reaktor killer for the blind
for several reasons. First of all there's no GUi really or no very easy
environment to simply load a particular synth and tweak away. If there
was an accessible GUi library for ChucK natively, and OO features like
reflectionand access to object symbol tables (read hash or dict), one
might be able to implement a facility that shows the user a list of
editable synth parameters, and let's you MIDI learn any of them, saving
the whole thing with the synth. This is very hard to do currently, you
have to hardcode controller values and right some of the MIDi handling
logic yourself, unless I'm much mistaken.
The other major point is that ChucK's orientation is still at the
Reaktor core level or lower and the focus seems to be on experimental
sound design and DSP rather than on the modular end user level like that
of Reaktor, Vaz Modular or the Nord, for that matter. With that said,
there are very few analogs of the basic Reaktor building bloks at the
module level, the idea is that you program them in on an ad hoc basis,
which is fine if you just want to program. But if I'd like to use ChucK
as a conventional modular environment, emulating existing modular
patches and doing as little programming as you do in AHDL, when you plug
logic components together, then ChucK isn't currently very well suited
to that purpose. Of course, I'd like to handle patching textually,
that's much faster than trying to achieve accessible, direct
manipulation.
Of course, since ChucK is fully programmable, nothing would stop you
from recreating say the Reaktor 3 module library from scratch,
especially given how much content there's for chucK already and how well
the individual Reaktor modules have been documented. Still, this is a
very big job and something I'm not up to yet. However, this might work
well as a
collaborative project, if the scope was narrowed to very early releases
and an essential subset of the modules. The only thing I've emulated so
far is the audio switch, with a parameterizable number of inputs, if I
recall correctly.
Your idea of using OSC and XUl is an interesting one though I know very
little about both, I know much more about MIDI. Of the languages
mentioned I only know Perl really well. One thing that worries me,
though, is the accessibility of the Mozilla components. The thing is
with Dolphin's mediocre support for FireFox, it is not quite as
accessible as IE is just yet. So I'm afraid controls derived from it
might be unusable at worst, Thunder Bird sure is not usable with Dolphin
Supernova, much as I'd liek to. Testing is the only way to tell how well
this XUL thingy works, I suppose. I suspect you're using the Jaws screen
reader.
Finally, given that ChucK doesn't currently support the kind of work I'd
liek to do with it very well, and if you don't mind me asking, are there
other environments that maybe serve me better? Reaktor is out of the
question and somehow I've never been truely thrilled by SynthEdit. One
app in addition to C Sound I always see mentioned about Linux and
modulars is something called the Super Collider. Is that closer to what
I'm looking for and what are the major differences to ChucK? I seem to
recall Emacs being mentioned in that context, I've never gotten
EmacsSpeak to run, although have a Ubuntu VM here.
Last but not least, Rich, you might want to join the synth_programming
Yahoo group. In addition to me there's at least one blind synth knut
there, plus some mathematicians and programmers. We often talk about
exotic forms of synthesis, and in fact I learned about chucK on the
list, since my speech friendly pseudo code representations of modular
patches started to bear a resemblance to ChucK code, which someone
kindly pointedd out.
my $self = shift;
$self->Sleep(); # It is way beyond midnight localtime.
--
With kind regards Veli-Pekka Tätilä (vtatila@mail.student.oulu.fi)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila
Rich Caloggero wrote:
Rich Caloggero wrote:
There was a thread on this list back in January about control of chuck
via OSC, a Python package. I have a few questions:
First, I'm blind and use a screen reader. I want to build something that
allows me to control chuck sreds via a GUI. I don't like Python much
for programming, and am not sure if OSC would even work with my screen
reader (anyone have any quick demos I could try just to see if the
screen reader will deal with the UI toolkit at all)?
What I was thinking of doing is building something in Mozilla's XUL
language. This does have the ability to send network packets, and also
can execute shell commands. So, was thinking about writing code in
chuck and then pass arguments to each .ck file to change parameters. Of
course, this might not work so smoothly if we wanted to change things on
the fly. FOr this I guess I'd need to implement something like OSC's
message passing scheme in XUL.
Any advice, or suggestions? Anyone interested in rewriting audical so
it works with a screen reader? There are so many great software
synthesizers on the market now that work as both stand alone and/or
plugins to popular hosts like Cakewalk's Sonar, but none that I've ever
tried will allow the screen reader enough control to do real sound
design. With effort, one can usually figure out how to change presets,
but in a large number of cases even this is not possible. I was hoping
that chuck could be used to build a fully accessible sound designers
toolbox that could allow one to do things quickly and easily without
having to write too much code. I've obviously never used it because it
is very graphically oriented, but think of something like PD "Pure
Data". You aparently can build all sorts of neat stuff by just plugging
stuff together, without having to write a line of code.
Thanx for any thoughts/suggestions...
-- Rich
_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
