>From: Dave Robillard <drobilla(a)connect.carleton.ca>
>
>What's the best way to disconnect ports? I've thought of:
>
>- putting a handle in the middle of connection lines, so you can
>right-click them to get a menu
No no.
>- making the lines really thick, same deal as above
Make the lines thick only if it is visually justified.
If you only want grab the cable, then make the grabbing distance
long enough. The same for the grabbing distances of the ports.
When working fast, any tiny things are no no -- there are plenty
of examples on tiny things already.
Change the cable and the port colors when they are in focus, to
indicate that something can be done to them.
Probably three distances are needed:
-Port picking distance
-Cable-end picking distance
-Cable picking distance
If one may start a new cable by picking the port, then cable-end picking
distance must be slighly larger -- and the area between the port picking
distance and the cable-end picking distance are used to pick the ends
of the cables.
- Grab and drag the end of the cable; the cable-end picking distance
should be long enough so that grabbing a cable is possible even
if the port has multiple connections (Note: this does not delete
the cable)
- Grabbing both ends deletes the cable
Change color only of the end of the cable to indicate that it can be
picked up.
- Ctrl + mouse button 1 on a cable: deletes cable; the menu is
ok too, but I prefer faster ctrl+mb1
- Sweeping a rectangle area on canvas, followed by a deletion operation
Make enough alternatives because usability is a matter of choise.
Regards,
Juhana
Hi all!
I wanted to do a simple task. I just want to playback a raw file (16BIT,
stereo, 44100Hz). So I used the alsa_pcm_seq-howto and compied a bit of code
from it. But it doesn't work. I get the device read for playing and I get
sound... But it's just noise. I'm frustrated. I tried to copy the relevant
part out of the aplay-sources, but they have so many config stuff... Can
anyone help me with a bit of code or a place where I should just get some code
for only:
1. opening a raw-file
2. setting up the alsa-driver for playbakc
3. Read data from the file and write it to the soundcard.
I want nothing fancy. Just a stupid little part of c-code, which performs
just that task.
Kindest regards and thanks for any help
Julien
http://ltsb.sourceforge.net - the Linux TextBased Studio guide
---------------------------------------------------------
SBS C-LAB
Fuerstenallee 11
33102 Paderborn
Phone: (+49) 5251 60 6060
Fax: (+49) 5251 60 6065
www.c-lab.de/~wegge
Hi,
I wonder if Revo can be used as 4xstereo channel output (Delta410 at twice
the price can do it) under Alsa ? Will anyone try it ?
Delta 410 can do this:
http://www.avsforum.com/avs-vb/showthread.php?s=&threadid=342158
I wonder if Revo can also do it ...
Regards,
Robert.
"At last", Roboff says, "I have it." - from "Mask Of The Sun"
Hi LAD'ers,
I'm happy to announce the first release (0.1) of lakai, a small tool package
that allows to exchange data (samples, programs) between a Linux PC and an
Akai sampler (S2000 tested; other 2xxx/3xxx models might work or not) over
SCSI. This permits "complete backup" and "complete restore" of the sampler
RAM contents.
Availability:
http://sourceforge.net/projects/lakai (the web page was not updated yet)
Right now, everything is just shell-based, no GUI yet, and the tools are
rather rudimentary, the source is ugly and sprinkled with TODOs and printf's
etc. pp., but at least it WorksForMe(tm). I welcome comments, success stories
and bug reports, but my answers might take a while :-). All further info is
in the archive in the README - read it, it took me a while to put it together.
This stuff comes rather late - in fact, I created this sourceforge project
more than 4 years ago, and I have only been working on it very rarely for
a long time (and it's even quite small). The S2xxx model samplers are only
available second-hand today, and software-based samplers (like
http://www.linuxsampler.org) are already on the way. I am still very proud
that I finally got this baby out of the door. Ha! :-).
Enjoy,
Frank
--
Frank Neumann (Frank.Neumann(a)st.com), VIONA Development Center
STMicroelectronics, Karlstraße 27, 76133 Karlsruhe
>From: Dave Robillard <drobilla(a)connect.carleton.ca>
>
>Screenshot:
>http://chat.carleton.ca/~drobilla/patchbay.png
[ ... ]
>Eventually it will be a combined jack/alsa patch bay
How about adding an application menu from which user may
launch new applications and insert to the patchbay?
Patchbay would store application's command line parameters.
How about a custom application menu where user has edited the default
command line parameters? E.g., a Fluidsynth would start with a sample
file: "fluidsynth-808perc". Of course, applications should support
configuration and sample loading via command line.
How Alsa mixer relates to Patchbay? If I record Alsa's line-in,
the reverberated output should not be mixed to the recording.
And other way, if I record reverberation, the original should not
be recorded. Could there be a Alsa module which has more connections
than capture1,2 and playback1,2? When I launch Alsamixer, I would
control levels with it and use Patchbay for routing. Sounds difficult
if Alsa has only one recording source: "Mix".
>and if anyone has ideas for an elegant
>automatic-module-placement solution
How about manual placement first? User could organize the modules
and then save the whole thing to file. When user loads the file,
the display looks the same -- and also all applications are launched.
If applications are launched from shell or if Patchbay figures out
the currently running Jack/Alsa system, then automatic placement would
be needed. But I would like to always build the system from scratch
or from file with Patchbay.
Patchbay could recognize all new applications launched from shell.
Usually one application is launched at a time and manual placement
is no problem. Again, the end result can be saved to file and there
is no need to redo the placement each time.
Patchbay files could be inserted to the current patchbay. E.g.,
a reverb patch could have four reverb related modules which together
makes the reverb. That is, four different Jack applications.
Inserted Patchbay files may need null nodes. If multiple modules
needs the same input, then with the null node the inputs can be
combined. There is no Jack application for the null node.
User who inserts the reverb to the patchbay then don't have to guess
how to connect the inputs to the reverb related modules -- their
inputs would not be connected at all without the null node.
A subpatches/macros would make the same thing, but would be more
complicated.
Should users be able to set the launching order of applications
in the patchbay files?
Regards,
Juhana
Hello.
How about writing an interactive demostration application which can
be set to conference booths and which with visitor could easily
check demos of applications.
The display could be a full screen window with a matrix of buttons.
Button would be labeled with the application names. When visitor
presses the button, the display changes to a possibly animated
screenshot of the application and an example audio would be
played. The application display could have a column of buttons
which can be used to change the example audio. Each example could
have its own screenshot.
The audio and the screenshot need not be entirely related.
One button could demostrate an editing feature and could have
no audio (or have some background music).
Screenshot could be, or have, an info text as well. Each different
display would be precomposed with GIMP and the like. The display
app should be as simple as possible -- also for us who would make
the content to it.
In any case, the actual applications would not be run at all.
It is important that the display app is fully working at all
of the times -- and not being idle like the real applications
would be.
Regards,
Juhana
>From: Joern Nettingsmeier <nettings(a)folkwang-hochschule.de>
>
>it is the author's decision, and everybody *has*to*respect*it*!
>don't preach freedom and deny others their freedom of choice. we've
>had enough of this bigotry lately.
I understood the frustation comes from wasting time to load the
software and to find out it is only executable.
Here (was it jackit-dev) most announced software are open source,
so it would be a good idea to let people know that now something
different is announced. But in any case, a good announce makes no harm.
Regards,
Juhana
>From: "Stefan Nitschke" <stefan_nitschke(a)hotmail.com>
>
>Its not my intention to blame Linux or the Linux-Community but it is
>in consequence the only way to prevent such postings in the future.
Write in your announces that the software is executable only!!
Simple as that.
Regards,
Juhana
Hi,
News for those interested in TAP plugins:
tap-plugins-0.3.0 is out.
* TAP AutoPanner
Implementation of a very well-known effect.
Useful mainly to liven up synth tracks.
* TAP DeEsser
A plugin for attenuating harsh 'ess' and 'ssh'
sounds in vocal recordings. Also usable on wind
instruments.
* Project moved to SourceForge.net.
New (and hopefully ultimate) homepage:
http://tap-plugins.sf.net
Enjoy!
Tom
