Hello Stéphane,
this is great, thank you!
(I just updated the code on github)
all the best,
Vince
On 09/25/2018 02:12 PM, l...@grame.fr wrote:
The code can be adapted like this:
// compile with: faust2jaqt -soundfile drumsequencer.dsp
//
https://github.com/grame-cncm/faustlibraries/blob/41163d260be908778d638e1d0211626b8b22b7e7/soundfiles.lib
import("stdfaust.lib");
process = k, hh, sn :> _,_;
looplength = 16;
bpm = hslider("bpm",120,40,240,1)*2;
beat_seq = ba.beat(bpm) : ba.pulse_countup_loop(looplength-1,1) :
hbargraph("seq",0,looplength-1);
playhead(x) = (1:+~_*trigger(x): _*1); // _*1 is speed
trigger(x) = steps(x) : par(i,looplength, _<: (_>_@1) : _) :> 1-_ ;
steps(x) = hgroup("%x", par(i,looplength, checkbox(" %2i "))) : par(i,
looplength, _*(beat_seq==i));
vol(v) = !,!,_*v<:_,_;
k = 0, playhead(1) : soundfile("label[url:k.wav]",1) : vol(k_vol);
hh = 0, playhead(2) : soundfile("label[url:hh.wav]",1) : vol(hh_vol);
sn = 0, playhead(3) : soundfile("label[url:sn.wav]",1) : vol(sn_vol);
// A single 'soundfile' can now be used
//sound = soundfile("label[url:{'k.wav';'hh.wav';'sn.wav'}]",1);
//k = 0, playhead(1) : sound : vol(k_vol);
//hh = 1, playhead(2) : sound : vol(hh_vol);
//sn = 2, playhead(3) : sound : vol(sn_vol);
k_vol = vslider("/h:volume/1 k[style:knob]",1,0,2,0.01);
hh_vol = vslider("/h:volume/2 hh[style:knob]",1,0,2,0.01);
sn_vol = vslider("/h:volume/3 sn[style:knob]",1,0,2,0.01);
Note that I’ve just fixed an issue in Soundfile handling in
https://github.com/grame-cncm/faust/commit/486d8da113959b44c5c5c7a2acc3474ac282d922
, so that first version (with 3 uses of ‘soundfile’) now works.
Stéphane
Le 24 sept. 2018 à 22:28, Stéphane Letz <l...@grame.fr> a écrit :
Excellent !
@Vince : Note that we change the soundfile semantic a bit to make it more
powerfull, it now takes a list of files in a same « soundfile » object. Here
is the current documentation:
=============
The soundfile("label[url:{'path1’;’path2’;’path3’;}]", n)’ primitive allows to access a
list of externally defined sound resources, described as the list of their filename, or
completepaths.The soundfile("label[url:path]",n) simplified syntax allows to use a single
file.
A soundfile has:
• two inputs : the sound number (as a integer between 0 and 255 checked at
compilation time), and the read index in the sound (which will access the last
sample of the sound if the read index is greater than the sound length)
• two fixed outputs : the first one is the currently accessed sound length in
frames, the second one is the currently accessed sound nominal sample rate in
frames
• several more outputs for the sound channels themselves
If more outputs than the actual number of channels in the soundfile are used,
the sound channels will be automatically duplicated up to the wanted number of
outputs (so for instance if a stereo sound is used with four output channels,
the same group of two channels will be duplicated).
If the soundfile cannot be loaded for whatever reason, a default sound with one
channel, a length of 1024 frames and null outputs (with samples of value 0)
will be used. Note also that soundfiles are entirely loaded in memory by the
architecture file, so that the read index signal can access any sample.
Architecture files are responsible to load the actual soundfile. The SoundUI
C++ class located in the faust/gui/SoundUI.h file implements the void
addSoundfile( label, url, sf_zone) method, which loads the actual sound files
using the libsndfile library, or possibly specific audio file loading code (in
the case of the JUCE framework for instance), and set up the sf_zone sound
memory pointers. If label is used without any url metadata, it will be
considered as the soundfile pathname.
Note that a special architecture file can perfectly decide to access and use
sound resources created by another means (that is, not directly loaded from a
soundfile). For instance a mapping between labels and sound resources defined
in memory could be used, with some additional code in charge to actually setup
all sound memory pointers when void addSoundfile(label, url, sf_zone) is called
by the buidUserInterface mechanism.
=============
See also :
https://github.com/grame-cncm/faustlibraries/blob/bc54091ab7134f7f71f81b8e443556784abb901b/soundfiles.lib
So you’ll have to adapt your DSP for the new semantic. Not that the
architecture code (that load files..etc…) is still fresh; Your faustdrumseq is
a very good use case. Testing welcome !
Stéphane
Le 24 sept. 2018 à 21:56, azvinz <azv...@yahoo.de> a écrit :
@Stéphane: here is the dsp, it is a simple drum sequencer (thank to the new
soundfile option!):
https://github.com/sonejostudios/faustdrumseq
@Julius: Your solution works! It doesn't show two digits but at least the order
is correct. Thank you!
All the best,
Vince
On 09/24/2018 08:02 PM, Julius Smith wrote:
You can say "[%2i]" to get two-digit fields.
- Julius
On Mon, Sep 24, 2018 at 2:33 AM Stéphane Letz <l...@grame.fr> wrote:
Can you send your DSP test code? (I remember using the %i syntax with
additional spaces should work…)
Stéphane
Le 23 sept. 2018 à 18:40, azvinz via Faudiostream-users
<faudiostream-users@lists.sourceforge.net> a écrit :
Hello everybody,
I have a small question concerning parallel compositions for GUI elements:
"i" started counting at 0, but not at 00, so the final order on the GUI (jaqt)
looks like this:
0,1,10,11,12,13,14,15,16,2,3,4,5,6,7,8,9
Is there a way to solve this?
I'm trying to write a step sequencer, but with this wrong gui order it is not
usable :(
Thank you in advance,
Vince
_______________________________________________
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
_______________________________________________
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
_______________________________________________
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
