Hi,
I'm Carlo and I started out Shelljam to provide a way of using any
standard computer hardware as an input device to make music with. Uses
like altering sounds with joysticks or simply playing chords on
keyboards are examples really great uses that come to mind, but there is
no inherent limitation.
Currently, the most important things that need to be done with Shelljam
are SCHED_FIFO realtime implementation and possibly threading
implementation (I suspect the threading gains would only start to get
visible when a large number of devices are used at once).
Personally I would like to minimize my time spent coding and maximize my
time spent producing music, although I have a fairly deep insight into
C++ and I can work closely with you to produce a Free Software
application that has the potential to create a whole movement of young
and/or open minded people to enrich our Free Music landscape by reducing
the entry cost to produce extremely good-sounding music.
Please contact me at capocasa :-:-:AT:-.-.- gmx :--DOT-.-.- Net if
you're at all interested!
Carlo
Greetings,
So here comes the time for another public release of the (cute) FluidSynth
Qt Interface: Qsynth 0.2.5 is out!
Just as one can read from the change log:
- New dial-knob behavior now follows mouse pointer angular position,
almost similar to old QDial, but this time avoiding that nasty and rather
abrupt change on first mouse click.
- By simple use of widget subclassing, the value/position of any dial knob
can now be reset to its default or original position at any time, by
simply pressing the mouse mid-button. These default value positions are
just committed to current dial values when switching engines and/or
closing the application.
- Optional specification of alternate fluidsynth installation path has
been added to configure command arguments (--with-fluidsynth).
- After some source code tweaks, a win32 build is now possible
(instructions will be provided on demand :)
- Bank offset finally gets its due effect, while on the channels and
channel preset selection dialogs. Regretfully, the soundfont bank offset
feature has been lurking ever since its inception, but now its live and
hopefully effective.
- A new fancy widget has arrived, qsynthKnob, with some modifications to
replace the actual *ugly* QDial widgets in the main window. This widget is
based on a design by Thorsten Wilms, formerly implemented by Chris Cannam
in Rosegarden, and finally adapted and brought to Qsynth by Pedro
Lopez-Cabanillas. Thankyou all.
Available from the usual places:
http://qsynth.sourceforge.nethttp://sourceforge.net/projects/qsynth
Enjoy.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Greetings,
So here comes the time for another public release of the (cute) JACK Audio
Connection Kit - Qt Interface: QjackCtl 0.2.20 is out!
Just as one can read from the change log:
- Server path setting now accepts custom command line parameters (after a
kind suggestion from Jussi Laako).
- The internal XRUN callback notification statistics and reporting has
been changed to be a bit less intrusive.
- Patchbay socket dialog gets some more eye-candy as icons have been added
to the client and plug selection (combobox) widgets.
- Connections and patchbay lines coloring has changed just slightly :)
- New patchbay socket forwarding feature. Any patchbay socket can now be
set to have all its connections replicated (i.e. forwarded) to another
one, which will behave actively as a clone of the former. Forward
connections are shown by vertical directed colored lines, and can be
selected either on socket dialog or from context menu (currently
experimental, only applicable to input/writable sockets).
- Optional specification of alternate JACK and/or ALSA installation paths
on configure time (after a patch from Lucas Brasilino, thanks).
Available from the usual places:
http://qjackctl.sourceforge.nethttp://sourceforge.net/projects/qjackctl
Enjoy.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
> i'm not sure which file you mean? i tried adding it
> to the top of dssi-vst-server.cpp, but that didn't
> work ... is that the one you meant?
Yes, but I realise I was misreading the error (it was
from the linker, not the compiler). How about an
extra "-lpthread" in LDFLAGS or whatever in the
Makefile?
Chris
Hi Devs, hi Chris
I've just compiled dssi-vst 0n openSUSE10.0 successfull. I'm using wine
0.9.8, liblo 0.22 (build failed with liblo 0.23 because of a linking
prob) and vstsdk 2.4.
dssi-vst works nearly well with the latest rosegarden4 for suse (and the
JAD2 RT kernel). I also get energyXT.dll to work standalone and inside
rosegarden.
dssi-vst works now more stable and faster. Thanks Chris for this
helpfull software and your distribution friendly licence. JackLab will
offer a binary rpm of dssi-vst 0.4 the next days.
More Info www.jacklab.net
Michael
> dssi-vst-server.cpp: undefined reference to `pthread_mutex_trylock'
Does the file (I don't have it to hand and am not at a
proper computer) have
#include <pthread.h>
at the top? If not, what if you add it? It may just
be that another header includes this on other
systems, but not on yours.
Chris
hi, i've been waiting for some help on building dssi-vst 0.4 (recently released), but thought i'd ask around some more ...
On Wed, 2006-03-01 at 13:17 +0000, Chris Cannam wrote:
> dssi-vst: a DSSI plugin wrapper for Win32 VST plugins
> =====================================================
>
> dssi-vst 0.4 is now available.
>
> The main change since the 0.3.1 release is that dssi-vst now builds with newer
> versions of the Wine tools. Wine 0.9.5 or newer is now required.
>
> This release also builds with version 2.4 of the VST SDK, although it should
> still work with the older 2.3 as well.
>
> Download it from:
> http://sourceforge.net/project/showfiles.php?group_id=104230&package_id=127…
>
> You will also need the VST SDK, from:
> http://www.steinberg.de/Steinberg/Developers8b99.html
>
> More information about DSSI:
> http://dssi.sourceforge.net/
>
oh, i've been waiting for this ... thanks for updating to be compatible
with latest Wine!!!
unfortunately, i get errors when trying to build:
[mrmachine@machine dssi-vst-0.4]# make
g++ -I./vstsdk2.4/pluginterfaces/vst2.x -Wall remotepluginclient.cpp -c
g++ -I./vstsdk2.4/pluginterfaces/vst2.x -Wall remotepluginserver.cpp -c
g++ -I./vstsdk2.4/pluginterfaces/vst2.x -Wall -c -o rdwrops.o
rdwrops.cpp
g++ -I./vstsdk2.4/pluginterfaces/vst2.x -Wall -c -o paths.o paths.cpp
ar r libremoteplugin.a remotepluginclient.o remotepluginserver.o
rdwrops.o paths.o
ar: creating libremoteplugin.a
wineg++ -I./vstsdk2.4/pluginterfaces/vst2.x -Wall dssi-vst-server.cpp -o
dssi-vst-server -L. -lremoteplugin
dssi-vst-server.cpp: In member function ‘virtual void
RemoteVSTServer::hideGUI()’:
dssi-vst-server.cpp:566: warning: unused variable ‘fd’
dssi-vst-server-5Pa9Gf.o(.text+0x147e): In function
`RemoteVSTServer::process(float**, float**)':
dssi-vst-server.cpp: undefined reference to `pthread_mutex_trylock'
collect2: ld returned 1 exit status
winegcc: g++ failed.
make: *** [dssi-vst-server.exe.so] Error 2
i'm using a CCRMA-enabled Fedora Core 4.
shayne
So it looks like I may be at LAC2006. I was thinking of bringing my SO
and spending a few days sightseeing after the conference, since we've
never been to Germany. Any recommendations for interesting stuff to do
in the area? We are into nature hikes, history, good restaurants -
pretty boring actually ;-)
Lee
Wow - that's quite a backlog of work.
The software looks fascinating - and the bush-o-matic is priceless!
Loved the personal stuff - you have a beautiful family.
Thanks for sharing, Brad. :)
- Maluvia
>Hey everyone --
>
>Sorry about the multiple postings, but I figured what the heck...
>
>I've just put on-line a whole lot of work I've done; papers, pieces,
>software, etc. Here's the link for the 2-3 people (beyond my immediate
>family) who might be interested:
>There's a fair amount of unix/linux work scattered throughout, including
>the big "My Music Book" thing I did a few years ago.
>
>Hope you enjoy this!
On Wednesday 01 March 2006 12:51, Julian Storer wrote:
> James Courtier-Dutton wrote:
> > "default" means just that. use the name "default" instead of
> > plughw:.... or hw:0,0
[...]
>
> Ok, at the risk of "spreading the myth" that the ALSA documentation is
> bad... is this stuff actually explained anywhere?? It took me a day of
> googling just to find out what the two numbers after "hw" meant! I never
> saw anything mention "default" or "plug:front", etc.
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html#pcm_dev_names
Regards,
Pedro
