The Sineshaper is a monophonic DSSI synth. This is the first release.
Source tarball, screenshot and Vorbis demo are available here:
http://ll-plugins.sf.net. The knob graphics are created by Thorsten
Wilms and Peter Shorthose.
The Sineshaper synth has two sine oscillators and two waveshapers.
The sound from the two oscillators is mixed and passed through the
waveshapers, first through the first waveshaper and then the second.
You can control the tuning of both oscillators as well as their
relative loudness, and the total amount of shaping and the fraction of
that amount that each shaper applies. Both waveshapers use a sine
function for shaping the sound, but for the second shaper you can shift
the sine function (with maximal shift it becomes a cosine function) to
produce a different sound.
You can also add vibrato and tremolo, and change the ADSR envelope
that controls the amplitude and shape amount (as well as setting the
envelope sensitivity for both the amplifier and the shapers). There
is also a "Drive" control that adds distorsion, and a feedback delay
with controllable delay time and feedback amount. All control parameters
can be changed using MIDI.
The Sineshaper synth comes with some presets that you can play or use
as starting points for your own synth settings. You can not change
these "factory presets", but you can create and save your own presets.
They are written to the file .sineshaperpresets in your home directory.
If you make any nice presets I would really like to hear them.
--
Lars Luthman
PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
> Are you using a customized jackd? What version? What command line? Do
> you have any evidence that anyone has ever made this work?
>
Opps, sorry for skipping obviously needed details. Was really upset.
I tried freebob + jackd from freebob.sf.net.
libavc from svn, libiec61883 1.0, libraw1394 1.2
cmdline: jackd -d iec61883 -o osc.udp://localhost:31000
FreeBoB wiki's list of working setups contains FA-101 + gentoo (my distro).
When run in the first time, jackd starts, but there's no sound, and
seems processing callbacks aren't called (no interrupts?).
Dmitry.
Hi!
I have been thinking about combining sequencing, (live) looping
and sampling.
I call the concept I arrived at Transport Regions for now (might
call it Areas, Scopes, Frames ... a native speaker's take on this?).
A Transport Regions groups n tracks, defining a common playback
posistion and transport state (playing, paused, reverse ...).
Loops can be defined with Markers.
A 'classic' sequencer/daw project would use only 1 Region, but
having several could allow sooperlooper like action, with the
advantage of simple extension, moving on from jamming to
production.
Transport commands to specific Regions could be recorded and
played back themselves.
Instrument type samples could be treated the same, with the
known markers, just for rather short loops, provided transport
actions could be mapped to midi/notes.
Multisampling would require means to map (midi) parameters
to track level changes and/or soloing/muting.
Patterns could actualy be Transport Regions triggered from a
track, from which they would need to 'inherit' tempo for normal
operation.
Well ... just food for thought!
---
Thorsten Wilms
On Fri, 2005-10-21 at 14:48 -0700, Mark Knecht wrote:
> > I think this would be a better question for the Freebob list, and cc:
> > the jackit-devel list, as you're using a version of JACK that the
> > Freebob people have customized. I've never heard anyone on LAD or LAU
> > report that this works.
> >
> > First and foremost, we need to get the iec61883 driver into JACK CVS, so
> > that Paul Davis and the other JACK experts can help you.
> >
> > Lee
>
> In case some folks don't know this stuff iec61883 is part of the 1394
> stack. Why would it go into Jack CVS?
Sorry, I mean "the iec61883 backend". JACK used to call these "drivers"
but as you can see it's confusing. JACK does not need to include the
iec61883 stack but it does need to know how to talk to it, just like
with ALSA, OSS, etc.
Look at his command line:
jackd -d iec61883 -o osc.udp://localhost:31000
If I run this I get:
rlrevell@mindpipe:~/kernel-source/linux-2.6.13$ jackd -d iec61883
jackd: unknown driver 'iec61883'
So he must be using a third party patch to jackd from the Freebob people
that implements the 'iec61883' backend.
Lee
Hi all,
just a note: A got it more or less working.
This morning I installed the vanilla-2.6.14-rc4 and I could start
jackd in realtime with -n6 -p256 and run ardour and
qsampler/linuxsampler in parallel without an xrun during normal
operation.
It just crashed jackd when I used -n6 -p128 but even after that it
didn't ruin the sounddriver so I could start jackd again.
That really takes a big stone from my heart as I have to do some
serious music with the laptop this weekend and I feared I had to mess
around with my old one...
So thanks for your patience,
Arnold
--
visit http://dillenburg.dyndns.org/~arnold/
---
Wenn man mit Raubkopien Bands wie Brosis oder Britney Spears wirklich
verhindern könnte, würde ich mir noch heute einen Stapel Brenner und
einen Sack Rohlinge kaufen.
I am in the early planning stage of an audio processing application and I
have come to the point of making the choice between floating point or fixed
point (signed 2's complement) processing.
What do you think is better, and why? Why does jack use floating point? Why
does AES use fixed point in most of their standards?
I understand the technical difference between the formats, but...
I can't come to a conclussion.
The adavantages of floating point I see are:
- easier processing, specially amplification and mixing (multiplying by
fractions)
- more sse support, more packed array arithmetics
- relationship to voltage and SPL easier to understand. (1.0f vs. 2^31-1
max. values)
And its diadvantages compared to fixed point would be:
- generally slower, specially things like addition
- 30 bits of resolution for 32 bits of data in IEEE single-precision
(exponents larger than 0 not used for audio, neither are denormalized
numbers and redundant zeroes, infinities, etc), compared to the full 32 bits
of resolution of fixed point.
- non-linear saw-tooth-like precission (precission gets higher as mantissa
gets larger and then falls abruptly at the point the exponent is increased)
I am sure I fail to see the more important points and would be thankful for
any comments.
If it has been discussed on the list earlier, i am sorry to post it again. I
couldn't find it.
Greetigs, Dimitri
--
NEU: Telefon-Flatrate f�rs dt. Festnetz! GMX Phone_Flat: 9,99 Euro/Mon.*
F�r DSL-Nutzer. Ohne Providerwechsel! http://www.gmx.net/de/go/telefonie
Like said before good ideas. One thing that I agree
with is to have the playhead snap to the beginning of
a region when it is clicked on. This really would
speed up the editing process. Maybe something like
this could be toggled on or off in the options window.
Another thing is in range mode. I'd like to have it
so when you select a range that it would play that
range just by hitting spacebar or play from the
transport. As this would elimiate two mouse clicks.
Seems small but it really. Maybe have this in the
options window as well.
Also in range mode. Move the play head with a single
click would save alot of editing time. I know that if
you hit p this will happen whereever the mouse is, but
just clicking would be alot quicker.
I'm not complaining about the existing operations.
Ardour is awesome. I just like to be able to make
quick edits. And eliminating clicks and keystrokes
may not seem like much. But when you make possible
hundreds of edits a day, it makes a huge difference in
time.
--- AES_24_96 <pipelineaudio(a)hotmail.com> wrote:
> edit mode
>
> I propose an edit mode or maybe its a mouse mode
> that would
> allow editing tasks to be performed with MUCH higher
> speed
> and quite a few less keystrokes. A similar scheme
> has been used
> before to create an app with exponentially less
> clicks and
> keystrokes to perform many editing tasks than any
> other.
>
> In this mode, playback cursor and edit cursor would
> be
> one and the same, a VERY skinny line that drops, and
> stays
> wherever you left click the mouse in the edit
> window, either
> on the ruler or on a region itself.
>
> Windows type conventions would apply to the
> selection process.
> Click a region, then shift click another region, and
> those two
> regions plus any region in between would be
> selected. click a
> region and control click another region for
> selecting non
> contiguous regions, and keep control clicking till
> you have
> selected all the regions you want. Click a fader and
> shift click
> or control click another fader to move multiple
> faders at once.
>
> Simple stuff, some of which Ardour already has, m to
> drop a
> marker, s to split, r after making a range selection
> to define a
> storable range. "g" groups all selected regions
> together,
> whether on the same track or not, u ungroups
> selected regions.
>
> Let me flesh some of these out a bit. For grouping,
> all grouped
> tracks would be moved as one of them is, either in
> time or
> between tracks. As groups overlap each other they
> would be
> auto-crossfaded where relevant, according to the
> already
> excellent Ardour autocrossfade options. Very
> importantly,
> there would be a "overide group" button in the
> Ardour menu
> bar, to perform actions on regions without bothering
> other
> regions grouped with them. Turning the button off
> would
> restore the group action.
>
> Splits can be made in several ways. Clicking on a
> region and
> hitting s will split right where the cursor sits.
> Clicking in a
> trackspace without a region in it, or along the
> ruler then hitting
> s will split all regions under the cursor. Dragging
> a range
> along the ruler then hitting s will put a split at
> the very
> beginning and end of the selected range. Selected
> regions,
> selected by click shift click and/or click control
> click as
> described above would also be split by hitting the s
> key.
>
> Region editing would be similar to the way ardour is
> now.
> Resize by clicking and dragging on edges (would
> group with
> groups and selections). Control-click and drag on
> edges will
> time stretch or time compress, also groupable with
> groups and
> selections. Click dragging on the top edges of
> either side will
> control the fade in or fade out handle, same as
> now. Click
> dragging on the very top middle area of a region
> would control
> a per region volume trim. Right clicking a region
> will bring up
> a menu including things like reverse region, and
> open copy of
> region in audio editor.
>
> Mouse wheel editing would be somewhat different.
> With no
> modifier, scrolling the wheel will zoom time in and
> out,
> keeping the zooming centered around the cursor. In
> the event
> that zooming goes too far to keep centered, it will
> go back to
> the cursor center upon zooming back in.
>
> Snapping: Right clicking the "snap to" button brings
> up a speed
> menu where you can select whether to snap to ruler
> marks
> ( as defined in the ruler speed menu), time, SMPTE,
> measures, half notes, quarter notes, 8th notes, 16th
> notes,
> 32nd notes, 64th notes and 128th notes). Holding
> shift while
> dragging a region overrides snapping. The "show
> grid" next to
> the snapping button will show a grid *VISIBLE
> THROUGH
> REGIONS* with its points set according to the "snap
> to"
> speed menu.
>
> Time display: Somewhere on ardour will be a time
> details
> screen. Top bar will show the timestamp of the
> beginning of a
> range selection. In the event of no range selection,
> this will
> show the timestamp at the cursor. The middle bar
> will show
> the timestamp at the end of the range selection. The
> bottom
> bar will show the duration of the range selection.
> The main
> time display as Ardour has now can be right clicked.
> In the
> speed menu that pops up, you can select between
> SMPTE,
> MTC, time(hour, minutes, seconds, miliseconds),
> samples,
> and musical time( measures, quarter notes, 8th
> notes, etc...).
> Separately the ruler can also be right clicked to
> display the
> same options.
>
> More to come, but I think with these basics ardour
> would be
> more than workable for those of Linux Noobs us who
> have
> been abandoned by our parent software company.
>
> I know it sounds like a lot, but I think this would
> certainly
> result in many fewer commands to accomplish the same
> actions we have now, and actually be simpler to work
> with
> and use.
>
> _______________________________________________
> ardour-dev mailing list
> ardour-dev(a)lists.ardour.org
>
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org
>
__________________________________
Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/
Hi.
I am Paul, the author of ZynAddSubFX software
synthesizer.
I wrote a complete documentation of how the PADsynth
synthesis algorithm works. It includes the full
description of the algorithm: overview, text
description, diagrams, pseudocode; example C/C++
implementations and a ready-to-use C++ class.
Also, I included some audio examples into the page.
Please tell me your opinion about it.
I tried to make it to be easy understood and ready to
be implemented and/or used into your software
synthesizers. Everything (the algorithm, the examples,
the implementations, diagrams,etc) from this page are
released under Public Domain. You are welcome to
include and use this into your programs and I invite
the companies/developers who write software
synthesizers to use it. Also, I guess that the sound
banks producers will be very interesed about this ;)
I don't require anything for using it ;-) ; I just
want this to be spread, to be used to make beautiful
sounds.
It's page is at:
http://zynaddsubfx.sourceforge.net/doc/PADsynth/PADsynth.htm
Enjoy!
Paul
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com