Hi all!
I have decided to release finally SoundTracker v1.0.1. Lacking feedback
after the 1.0.1-pre1 release I had to spent enough time to test it
thoroughly. During this testing, I have found and fixed numerous bugs.
Now ST seems to be matured enough to be released.
You can download it here:
https://sourceforge.net/projects/soundtracker/files/
1.0.1 release contains no new features compared to 1.0.1-pre1, it is the
bugfixing release only. So its list of features is the same as for
1.0.1-pre1:
Regards,
Yury.
What is new in soundtracker-1.0.1 (29-Jul-2020):
* Improved mouse usage in the instrument editor (yaliaev)
* Indication of pressed keys in the instrument editor (yaliaev)
* Better look of the scopes (yaliaev)
* Record indicator in the sampling monitor (yaliaev)
* More configurable colors (yaliaev)
* Logarithmic scale of the amplification slider; numeric entry in
addition to
the slider; ability to determine the optimal amplification (yaliaev)
* Extended editor on the module info page with functions of exchanging and
copying samples and instruments, mixing samples and tuning a sample using
another one as a reference (yaliaev)
* Different selection modes in tracker, selection can be extended with SHIFT
(yaliaev)
* A new method of waveforms' drawing in the sample displays in addition to
the existing one (yaliaev)
* Automatic file extension adding (optional) (yaliaev)
* More convenient keybindings; new keybindings are added (see README)
(yaliaev)
* Some more keys are made configurable including that for song / pattern
playback (yaliaev)
* New playing modes are added: Playing selected block and Playng from
cursor,
playback looping control (yaliaev)
* Facility for loading somewhat broken modules (yaliaev)
* Stepping volume / FX parameter with mouse wheel (yaliaev)
* Improved export to audio file (yaliaev)
* Volume column can be displayed like in FT2, with letters, mnemonics and
optional decimal volume representation (yaliaev)
* Jack input driver (yaliaev)
* Improved live recording using PC keyboard: better key pressing / releasing
times are recorded using FXes (yaliaev)
* Some other small improvements (GUI, usability) (yaliaev)
* Some bugfixes including the CPU overhead with graphics (yaliaev)
Hi
Mamba release v1.1 is out
Mamba - Virtual Midi keyboard
https://github.com/brummer10/Mamba
Mamba features
* Virtual Midi Keyboard for Jack Audio Connection Kit
<https://jackaudio.org/>
* including NSM <https://linuxaudio.github.io/new-session-manager/>
support
* Channel selector
* Bank and Program selector
* Keyboard mapping for qwertz, qwerty and azerty selectable from menu
* PC Keyboard mapping selector from C0 to C4
* Pitchbend, Balance, Modwheel, Detune, Expression, Attack, Release,
Volume and Velocity controllers
* Sustain and Sostenuto switches
* Midi Through: forward midi input to output
* Midi input highlighting
* resizable to a full range 127 key view
* Midi live recording and looping
Mamba is released under the 0BSD license
regards
hermann
Hello,
it's time for a new release of B.Jumblr, a pattern-controlled
audio-stream & sample re-sequencer. Now it comes along with multiple
pattern pages and optional MIDI control.
What's new:
-----------
* Up to 16 pattern pages
* More compact GUI <-> DSP data transfer
* MIDI-controlled pattern playback
* MIDI learn
Repository: https://github.com/sjaehn/BJumblr
Releases: https://github.com/sjaehn/BJumblr/releases
Tutorial video: https://www.youtube.com/watch?v=DFSi7TMqvMw
Acknowledgments:
----------------
* Milkii Brewster for ideas about principle and features
* unfa for ideas about multiple patterns and automation
* Rob van den Berg for the plugin name
Enjoy and have fun
Sven Jaehnichen
Hi,
This is request-for-test (RFT) to the ALSA control service programs for
devices with Fireworks board module. The program is available in
'topic/service-for-efw' of below repository, and the RFT is corresponding
to Pull Request #2:
* https://github.com/alsa-project/snd-firewire-ctl-services/
If you have listed devices and handle them by ALSA fireworks driver, please
test the service program according to the below instruction.
* Mackie (Loud) Onyx 1200F
* Mackie (Loud) Onyx 400F
* Echo Audio Audiofire 12 (till Jul 2009)
* Echo Audio Audiofire 8 (till Jul 2009)
* Echo Audio Audiofire 12 (since Jul 2009)
* Echo Audio Audiofire 8 (since Jul 2009)
* Echo Audio Audiofire 2
* Echo Audio Audiofire 4
* Echo Audio Audiofire Pre8
* Gibson Robot Interface Pack (RIP) for Robot Guitar series
Background
----------
The models with Fireworks board module are already supported by ALSA
fireworks driver for their isochronous packet stream functionality
and vendor-specific transaction. Although the driver allows userspace
applications to process PCM frames and MIDI messages in the packet
streaming, it doesn't support the other functionalities such as volume
control since it can be achieved by any usespace application which
executes ioctl(2) to ALSA hwdep character device for the transaction.
The service program is to satisfy the demand to control the models.
ALSA control applications can request the control by IPC to the service
program.
In detail of mechanism, please read README.rst in the repository[1].
You can see some illustrations.
How to build
-------------
The project depends on several libraries in below repositories:
* glib[2]
* alsa-gobject v0.1.0[3]
* libhinawa v2.0.0[4]
Before building it, please install them with gobject-introspection support.
The project is written by Rust programming language[5] and packaged by
cargo[6]. To build, just run below commands in the environment to connect
to internet:
```
$ git clone https://github.com/alsa-project/snd-firewire-ctl-services.git -b topic/service-for-efw
$ cd snd-firewire-ctl-services
$ cargo build
```
All of required crates are downloaded automatically, then start build.
Executables
-----------
After building, `snd-fireworks-ctl-service` executable is available.
When running, the program adds and maintains control elements, then enter
event loop to dispatch events. The added elements are visible and manipulable
for any userspace applications. The program dispatch any manipulation
event for transactions to control actual device.
The executable has an option for the numerical ID of sound card.
```
Usage:
snd-fireworks-ctl-service CARD_ID
where:
CARD_ID: The numerical ID of sound card.
```
It's easy to run the executable by cargo, like:
```
$ cargo run --bin snd-fireworks-ctl-service 2
```
Receiving SIGTERM signal terminates the event loop, then the program
finishes.
During runtime, any ALSA control applications can enumerate and manipulate
the added control elements. This is an example of Echo Audio AudioFire 2:
```
$ amixer -c 2 controls
numid=33,iface=MIXER,name='clock-detect'
numid=2,iface=MIXER,name='clock-rate'
numid=1,iface=MIXER,name='clock-source'
numid=36,iface=MIXER,name='input-meter'
numid=34,iface=MIXER,name='midi-in-detect'
numid=35,iface=MIXER,name='midi-out-detect'
numid=6,iface=MIXER,name='monitor-gain'
numid=7,iface=MIXER,name='monitor-gain',index=1
numid=8,iface=MIXER,name='monitor-gain',index=2
numid=9,iface=MIXER,name='monitor-gain',index=3
numid=10,iface=MIXER,name='monitor-gain',index=4
numid=11,iface=MIXER,name='monitor-gain',index=5
numid=12,iface=MIXER,name='monitor-mute'
numid=13,iface=MIXER,name='monitor-mute',index=1
numid=14,iface=MIXER,name='monitor-mute',index=2
numid=15,iface=MIXER,name='monitor-mute',index=3
numid=16,iface=MIXER,name='monitor-mute',index=4
numid=17,iface=MIXER,name='monitor-mute',index=5
numid=24,iface=MIXER,name='monitor-pan'
numid=25,iface=MIXER,name='monitor-pan',index=1
numid=26,iface=MIXER,name='monitor-pan',index=2
numid=27,iface=MIXER,name='monitor-pan',index=3
numid=28,iface=MIXER,name='monitor-pan',index=4
numid=29,iface=MIXER,name='monitor-pan',index=5
numid=18,iface=MIXER,name='monitor-solo'
numid=19,iface=MIXER,name='monitor-solo',index=1
numid=20,iface=MIXER,name='monitor-solo',index=2
numid=21,iface=MIXER,name='monitor-solo',index=3
numid=22,iface=MIXER,name='monitor-solo',index=4
numid=23,iface=MIXER,name='monitor-solo',index=5
numid=38,iface=MIXER,name='monitoring'
numid=37,iface=MIXER,name='output-meter'
numid=31,iface=MIXER,name='output-mute'
numid=30,iface=MIXER,name='output-volume'
numid=4,iface=MIXER,name='playback-mute'
numid=5,iface=MIXER,name='playback-solo'
numid=3,iface=MIXER,name='playback-volume'
numid=32,iface=MIXER,name='stream-playback-routing'
```
Access permissions for relevant character devices
--------------------------------------------------
The executable manipulates below character devices to dispatch, and emit
events from end to end. The '%u' is the numerical number of instance in
each subsystem:
* ALSA control character device (/dev/snd/controlC%u)
* ALSA hwdep character device (/dev/snd/hwC%uD%u)
* Linux firewire character device (/dev/fw%u)
Feedback
--------
Any feedback is welcome. For questions, please use mailing list of alsa-devel
or alsa-users[7]. For issues, please use service of github.com[8].
Issues
------
The name of control elements are not fixed yet since the convention of
name for element set is not clear yet for recording equipment.
Users may feel inconvenience to which channel corresponds to which physical
port. Furthermore, in the case that element set includes several elements,
it's unclear that which element corresponds to which physical port as well.
ALSA control core has no feature for the above issues at present.
[1] https://github.com/alsa-project/snd-firewire-ctl-services
[2] https://gitlab.gnome.org/GNOME/glib
[3] https://github.com/alsa-project/alsa-gobject/
[4] https://github.com/alsa-project/libhinawa
[5] https://www.rust-lang.org/
[6] https://doc.rust-lang.org/cargo/
[7] https://www.alsa-project.org/wiki/Mailing-lists
[8] https://github.com/alsa-project/snd-firewire-ctl-services/issues
Regards
Takashi Sakamoto
Hi,
I had a hunch that's there is a way to trade latency for parallelism in
serial jack graphs (at least on jack2/jackdmp setups). Comments welcome..
https://github.com/fps/jack2_split
README.md below:
jack2_split
A program that facilitates parallelism in serial jack graphs by
introducing latency. Only useful for jack2/jackdmp - it does nothing but
add latency in jack1 setups.
What?
If you have a jack processsing graph that looks like this:
capture -> A -> B -> playback
where A and B are jack clients, then A and B must be scheduled in series
due to the linear dependency.
Running A and B serially might produce xruns (i.e. violate the
scheduling deadline imposed by jackd) while running only A or only B
might not.
jack2_split can be used to remedy the situation by using the following
graph:
capture -> A -> jack2_split -> B playback
jack2_split breaks the serial dependency by registering two jack clients
which respectively only have terminal input and output ports. It copies
the buffers from its inputs to its outputs after the current process
cycle. This introduces one additional period of latency into the graph,
but allows jack2/jackdmp to schedule A and B in parallel (e.g. on two
cores).
--
https://fps.io
I'm pleased to announce the release of guitarix2-0.41.0
A virtual guitar amplifier for Linux running with jack (Jack Audio
Connection Kit)
released under the GNU General Public License as published by the Free
Software Foundation;
either version 2 of the License, or (at your option) any later version.
This is a major release.
It introduce some new features and fix several bugs
Changelog:
* Add Slovak translation by Jozef Riha
* Fix issue #104 lv2 plugins contains executable stack, patch by
Alexander Tsoy
* Fix issue #105 Compile error on 0.40.0
* Fix issue #109 cannot initialize a variable of type 'char ' with an
rvalue of type 'void '
* Fix issue #110 error: unknown type name 'va_list'
* Add NSM support
* Add midi out for tuner
* Add low/high cut filter before tuner
* GxTuner set to use same precision then the tuner in guitarix
* Use tab-box for LV2 plugs with to much controls
* Disable GxVibe, because it is broken
* Fix several Bug's and hopefully don't introduce to much new one's
You could get it here:
https://sourceforge.net/projects/guitarix/
or here:
https://github.com/brummer10/guitarix
regards
hermann
Dear Linux Audio Dev Team,
I am looking to re implement and publish with the help of Wireshark a
software like Line6 PODHD 500x Edit for my POD HD500X (modification of
guitar pedal effects). To do this I need to claim the usb interface that
is already used by the snd-usb-podhd and redo the initialisation, also
already done by snd-usb-podhd. Therefore, to have both the audio and the
pedal management I would need to modify the module mentioned above. This
would aim to create a bridge between kernel and the userspace, that
redirects the usb urb bulk requests that are not used by the audio part,
to an interface (only isochronous is used after the init).
In the objective to be merged upstream in the future, how should I proceed:
* Use midi interfaces and create a fake one, knowing that the
proprietary but readable protocol is not midi compliant?
* Create a char device for the podhd pedal boards? Within the same module?
* Other suggestions?
In the same way, I am looking for suggestion regarding the data
transmitted within this interface. Would something like struct {int
message_len, char * data} be sufficient to be transmitted at every urb
bulk request?
Thanks in advance,
Nicolas SCHWARTZ
PS: I can share with you my test code and my current analysis on the
messages sent/received by the pod when clicking on buttons/sending
message from the PC, if needed.