Re: [tim-janik/beast] LiquidSFZ device (#145)

[Stefan Westerfeld via beast]

Closed #145.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/145#event-7549618282
You are receiving this because you are subscribed to this thread.

Message ID: ___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] LiquidSFZ device (#145)

[Stefan Westerfeld via beast]

I've created an Anklang PR here: https://github.com/tim-janik/anklang/pull/7 so 
I'll close this one.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/145#issuecomment-1272578402
You are receiving this because you are subscribed to this thread.

Message ID: ___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] BSE: Jack: add midi driver (#129)

[Stefan Westerfeld via beast]

This PR is about jack midi support which is not in Anklang (you only merged a 
jack pcm driver).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/129#issuecomment-1200058166
You are receiving this because you are subscribed to this thread.

Message ID: ___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Hydrogen import (#41)

[Stefan Westerfeld via beast]

Basically, liquidsfz tries to transparently load hydrogens xml format, and 
turns its xml content into .sfz opcodes. For instance if you use
```
$ liquidsfz /usr/share/hydrogen/data/drumkits/GMRockKit/drumkit.xml
```
you can use the hydrogen GMRockKit in liquidsfz. This works because a lot of 
what the python script has implemented for bsewave files is now also done (even 
somewhat more correctly as far as I remember) by

* https://github.com/swesterfeld/liquidsfz/blob/master/lib/hydrogenimport.cc

So as soon as Anklang has liquidsfz support, we also have most of what this bug 
report is about supported in Anklang.

What this doesn't do is
* looking for drumkits in well known folders
* downloading additional h2drumkits
* extracting h2drumkits
* displaying author and/or license infos

(which all could be done by Anklang)

It is also somewhat limited in terms of what hydrogen features are supported, 
but if we need more, we could improve the liquidsfz importer. In cases where 
there is no corresponding sfz opcode, we could invent our own private opcodes 
(i.e. liquidsfz_foo_bar=bazz for a hydrogen foo_bar=bazz feature). In these 
cases liquidsfz bugs could be filed.

Finally one problem here is that we don't split each drum into its own stereo 
bus. So you cannot for instance place a reverb on the base drum, but a 
different effect on the snare, as you only get a mixdown from liquidsfz which 
contains all drums. This is ok for a start, but suboptimal, but in theory we 
can implement it by extending the importer and adding new either public or 
private API to liquidsfz to support splitting its output in more stereo 
channels. Its a somewhat advanced feature though, and we probably can ignore it 
for now.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/41#issuecomment-1200041001
You are receiving this because you are subscribed to this thread.

Message ID: ___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

License Statement

[Stefan Westerfeld via beast]

   Hi!

I'd like to allow re-using my code contributions to BEAST according to
this license statement:

All of my past & future contributions to the Beast project
(https://github.com/tim-janik/beast) may be licensed under the
MPL-2.0+/LGPLv2.1+ dual license.

   Cu... Stefan
-- 
Stefan Westerfeld, http://space.twc.de/~stefan
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] LV2 support (#149)

[Stefan Westerfeld via beast]

@swesterfeld pushed 1 commit.

af9880a269e559e5be54f0687b7a63cd99d098b5  DEVICES: lv2device: add TODO items


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/tim-janik/beast/pull/149/files/9b9955206e74d6296a269139f17141bff34bceb6..af9880a269e559e5be54f0687b7a63cd99d098b5
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] LV2 support (#149)

[Stefan Westerfeld via beast]

@swesterfeld pushed 1 commit.

9b9955206e74d6296a269139f17141bff34bceb6  DEVICES: lv2device: call worker 
interface end_run() at end of run()


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/tim-janik/beast/pull/149/files/784b185608c84c55a8188e1d2c357d28058acb03..9b9955206e74d6296a269139f17141bff34bceb6
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] LV2 support (#149)

[Stefan Westerfeld via beast]

@swesterfeld pushed 1 commit.

784b185608c84c55a8188e1d2c357d28058acb03  DEVICES: lv2device: improve audio 
input/output channel->bus mapping


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/tim-janik/beast/pull/149/files/b993665a31c9c580e732e93a96b7ab5f9e5f702a..784b185608c84c55a8188e1d2c357d28058acb03
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] LV2 support (#149)

[Stefan Westerfeld via beast]

Ive been working on LV2 support. This is work in progress, so Im 
submitting the current version here, while I know the code is somewhat 
incomplete. As discussed previously, there is no custom UI support yet, and 
should be added once we have out-of-process support.

- the ringbuffer is a copy from jack driver, so probably we should have 
Bse::FrameRingBufferT and Bse::RingBufferT implemented in 
bse/ringbuffer.hh and used by both
- the code is used by specifying at LV2 URI (defaults to zynaddsubfx), like
```
LV2URI=http://synthv1.sourceforge.net/lv2 make run # synth
LV2URI=http://calf.sourceforge.net/plugins/Monosynth make run # synth
LV2URI=urn:ardour:a-reverb make run # stereo effect
```
- preset loading should not be done in RT thread (as discussed in last 
meeting), and notify UI, too
- there should be a way to select which plugin to use (LV2URI) other than 
commandline
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/149

-- Commit Summary --

  * DEVICES: lv2device: initial LV2 support
  * DEVICES: lv2device: support setting URI via env variable for testing
  * DEVICES: lv2device: map for plugin input control ports to device params
  * DEVICES: lv2device: activate instance before using it
  * DEVICES: lv2device: add initial supports for presets
  * DEVICES: lv2device: refactor plugin instance preset initialization
  * DEVICES: lv2device: add internal API to unmap urid - string
  * DEVICES: lv2device: initial implementation for worker extension
  * DEVICES: lv2device: use semaphore to synchronize worker thread
  * DEVICES: lv2device: join worker thread if plugin instance is deleted
  * DEVICES: lv2device: fix crash if no presets are available
  * DEVICES: lv2device: deactivate instance during destructor
  * DEVICES: lv2device: support plugins with audio input
  * DEVICES: lv2device: free instance when done, handle failed instantiate

-- File Changes --

M config-checks.mk (2)
A devices/lv2device/lv2_evbuf.cc (276)
A devices/lv2device/lv2device.cc (937)
A devices/lv2device/ringbuffer.hh (266)

-- Patch Links --

https://github.com/tim-janik/beast/pull/149.patch
https://github.com/tim-janik/beast/pull/149.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/149
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Native SpectMorph Support in Beast (#12)

[Stefan Westerfeld via beast]

I'm no longer recommending that we do this, we should rather use the LV2, see 
also

https://github.com/tim-janik/beast/pull/30#issuecomment-718844587


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/issues/12#issuecomment-718848071___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Native SpectMorph Support in Beast (#12)

[Stefan Westerfeld via beast]

Closed #12.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/issues/12#event-3937103728___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Spectmorph plugin (rebase) (#30)

[Stefan Westerfeld via beast]

I've implemented a preliminary version of a SpectMorph Device for BEAST here: 

  
https://github.com/swesterfeld/beast/blob/spectmorph/devices/spectmorph/spectmorph.cc

Some things (custom ui/serialization) are not finished. However, there is a 
general problem that arises if a user uses multiple versions of SpectMorph at 
the same time, as the ~/Documents/SpectMorph/Instruments/User directory is 
shared between all SpectMorph instances. Unexpected results are produced if one 
version would be linked into BEAST and another version was installed for 
LV2/VST. Therefore I think to avoid problems with incompatible versions 
accessing the custom instuments directory, I instead recommend that BEAST uses 
the LV2 plugin (just like every other DAW). So this PR can be closed now.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/30#issuecomment-718844587___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Spectmorph plugin (rebase) (#30)

[Stefan Westerfeld via beast]

Closed #30.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/30#event-3937076917___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] LiquidSFZ device (#145)

[Stefan Westerfeld via beast]

@swesterfeld pushed 1 commit.

bd50c86918a28248a88d4d6046b648b9557940ee  DEVICES: liquidsfz: use liquidsfz API 
to stop voices / reset state


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/tim-janik/beast/pull/145/files/ea5795cced81f74559194e61973591635a553f08..bd50c86918a28248a88d4d6046b648b9557940ee
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

spectmorph-0.5.1

[Stefan Westerfeld via beast]

spectmorph-0.5.2 has been released.

The two new main features (synchronizing morphing with the song tempo
and positional play) are explained here: https://youtu.be/6E4HClXdV_Y

If you haven't watched our video tutorial for the instrument editor
added in 0.5.0, you can do so here: https://youtu.be/JlugWYPDp84

Overview of Changes in spectmorph-0.5.2:

* Support bpm/beat synchronization for LFO
  - new presets using beat sync LFO: Mars / Saturn
* Add WavSource custom position playback mode
* New Instruments: Sven Ah / Ih / Oh (another male human voice)
* Store data in XDG directories on Linux:
  - move ~/.spectmorph directory to $XDG_DATA_HOME/spectmorph
  - move ~/SpectMorph directory to $XDG_DOCUMENTS_DIR/SpectMorph
  - create $XDG_DOCUMENTS_DIR/SpectMorph directory when needed (on write)
  - backward compatibility: use ~/SpectMorph if it already exists
* Bump number of control inputs from 2 to 4
* Implemented midi CC control for smjack (General Purpose Controller 1..4)
* Fix crashes caused by dangling MorphOperator pointers
* Fix loading floating point wav files
* Minor fixes and cleanups

What is SpectMorph?
---
SpectMorph is a free software project which allows to analyze samples of
musical instruments, and to combine them (morphing). It can be used to
construct hybrid sounds, for instance a sound between a trumpet and a
flute; or smooth transitions, for instance a sound that starts as a
trumpet and then gradually changes to a flute.

SpectMorph ships with many ready-to-use instruments which can be
combined using morphing.

SpectMorph is implemented in C++ and licensed under the GNU LGPL version 3

Integrating SpectMorph into your Work
-
SpectMorph is currently available for Linux, Windows and macOS users.
Here is a quick overview of how you can make music using SpectMorph.

- VST Plugin, especially for proprietary solutions that don't support LV2.
  (Available on Linux and 64-bit Windows/macOS)
- LV2 Plugin, for any sequencer that supports it.
- JACK Client.

Links:
--
Website:  http://www.spectmorph.org
Download: http://www.spectmorph.org/downloads

There are many audio demos on the website, which demonstrate morphing
between instruments.
-- 
Stefan Westerfeld, http://space.twc.de/~stefan
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] LiquidSFZ device (#145)

[Stefan Westerfeld via beast]

Here is an implementation of a LiquidSFZ device. The obvious next step would be 
allowing the user to specify file. Loading might want to use an extra thread, 
so that it doesnt block anything.  SFZ files can take a long while to load.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/145

-- Commit Summary --

  * config-checks.mk: add liquidsfz as build dependency
  * DEVICES: liquidsfz: add LiquidSFZ device for SFZ support
  * DEVICES: liquidsfz: map .sfz CCs to processor parameters

-- File Changes --

M config-checks.mk (2)
A devices/liquidsfz/liquidsfz.cc (101)

-- Patch Links --

https://github.com/tim-janik/beast/pull/145.patch
https://github.com/tim-janik/beast/pull/145.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/145
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Support wave-form plotting for BlepSynth (#144)

[Stefan Westerfeld via beast]

Just one more comment on this code: I saw that if you use a very small 
pulse_width and make sync really high then not all pulses will be visible. A 
higher number of samples would help, but I think we may want to make the 
minimum pulse width depend on the sync factor (to plot a wider pulse in order 
to be able to display it properly). But such fine tuning would be easier if the 
wave form would be displayed.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/144#issuecomment-664004225___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] Support wave-form plotting for BlepSynth (#144)

[Stefan Westerfeld via beast]

It would be nice if the oscillator wave form (which depends on the oscillator 
parameters) could be displayed at the UI. Ive ported the necessary 
plotting code from Python (plotblep.py) to C++.

The actual waveform is sampled, so one parameter to tune might be how many 
samples to use. Or the overlap (copy_samples). Finally we currently dont 
have the infrastructure to display this, so when enabled, the wave forms of 
both oscillators are written to /tmp/plot1 and 
/tmp/plot2, just to be able to test it.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/144

-- Commit Summary --

  * DEVICES: blepsynth/plotblep.py: fix minor plotting bug
  * DEVICES: blepsynth/blepsynth.cc: add oscillator shape plotting code

-- File Changes --

M devices/blepsynth/blepsynth.cc (118)
M devices/blepsynth/plotblep.py (3)

-- Patch Links --

https://github.com/tim-janik/beast/pull/144.patch
https://github.com/tim-janik/beast/pull/144.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/144
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] BlepSynth initial implementation (#142)

[Stefan Westerfeld via beast]

Closed #142.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/142#event-3570575327___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] BlepSynth initial implementation (#142)

[Stefan Westerfeld via beast]

Ok, now that this is merged I think we can close the issue, certainly the other 
issues can be sorted out later, we can't have everything at once.
 
> > TODO: under some conditions we could enable SSE in LadderVCF (alignment and 
> > block_size) *
> 
> * Anything needed for that from my part? We already utility SIMD and 
> auto-vectorization in the production build.

No. I'll do that once I have the time.

> > TODO: we need non-linear translation between percent and time/level
> 
> * Same here, does the discussion we previously had on panning help here?

I think we had this working. Note that sustain is still missing, there should 
be a non-linear mapping for sustain% to level.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/142#issuecomment-661778372___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] Blepsynth improvements (#143)

[Stefan Westerfeld via beast]

Here is a bunch of new stuff for BlepSynth, I wont try to reproduce the 
commit entries here. Only a few additional observations:

* x^3 non-linear adsr time scaling used to work but now it doesnt probably 
due to parameter API changes (I didnt try to fix it)
* some parameters (octave, unison voices) need step=1 but I havent seen 
how to set it when registering a parameter, so this workarounded a bit by 
overriding param-to-text conversion and omitting decimals
* new filter envelope is hard-wired to modulate cutoff, whereas it would make 
sense if it could modulate any parameter, but we dont have the ui for 
selecting modulation targets yet (nor the infrastructure bits)

You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/143

-- Commit Summary --

  * DEVICES: blepsynth: copy remaining relevant files from bleposc branch
  * DEVICES: blepsynth/blepsynth.cc: we have midi input, remove note toggles
  * DEVICES: blepsynth: add smoothing for cutoff frequency, add drive property
  * DEVICES: blepsynth: clean up old note toggles helper function
  * DEVICES: blepsynth: display unison voice text as integer
  * DEVICES: blepsynth: support osc octave + pitch properties
  * DEVICES: blepsynth: add linear ADSR shape for Envelope
  * DEVICES: blepsynth: add filter envlope and cutoff modulation
  * DEVICES: blepsynth: smooth Env Cutoff Modulation to avoid clicks
  * DEVICES: blepsynth: stop filter envelope at note off
  * DEVICES: blepsynth: add filter key tracking

-- File Changes --

A devices/blepsynth/TODO (9)
M devices/blepsynth/blepsynth.cc (176)
A devices/blepsynth/bleputils.hh (47)
A devices/blepsynth/designblep.cpp (365)
A devices/blepsynth/linearsmooth.hh (60)
A devices/blepsynth/plotblep.py (212)
A devices/blepsynth/testblep.cpp (757)

-- Patch Links --

https://github.com/tim-janik/beast/pull/143.patch
https://github.com/tim-janik/beast/pull/143.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/143
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: Blepsynth Cutoff Range

[Stefan Westerfeld via beast]

   Hi!

Am 14.07.20 um 03:19 schrieb Tim Janik:
> the Blebsynth Filter range is currently created as 20..24000:
> 
>> pid_cutoff_ = add_param ("Cutoff", "Cutoff", 20, 24000, 1000, "Hz", STANDARD 
>> + "logcenter=880:");
> 
> Those boundaries don't fit exactly for a straight logarithmic mapping like
> you gave in the comment below, if you also want a straight mapping of
> pixels to octaves (i.e. map 0..1 to an integer set of octaves).

I don't want an integer number of octaves - see below.

> The value range closest to the current boundaries that I could find is
> centered around F#5 (739.99Hz):
> 
> begin=440 * 2**(9/12.) / 2**5. ; end= 440 * 2**(9/12.) * 2**5.
> print begin, end
> 23.1246514194771 23679.6430535446
> 
> Let me know if I should use different boundaries when I'm implementing
> logarithmic parameters.

Is there a reason why you want to have "whole" octaves? Two examples for
possible cutoff ranges:

 - 20..24000 corresponds to log(24000/20)/log(2) = 10.23 octaves
 - 20..3 corresponds to log(3/20)/log(2) = 10.55 octaves

I don't see any reason to quantize the ranges as to enforce choosing
either 10 or 11 octaves instead of implementing the ranges exactly. As
long as the mapping is logarithmic it should be ok for the user for
automation and ui controls, even if we don't have an integer number of
octaves.

I would understand if for some reason you want to quantize the
lower/upper bound to an integer number midi note.

   Cu... Stefan
> 
> 
> On 13.07.20 13:13, Stefan Westerfeld via beast wrote:
>> I have just added logscale mappings
>>
>> The mappings you added are obviously useful, especially for milliseconds 
>> (x^3)
>> mappings, but these are /not logscale/. A true logscale mapping plots as 
>> line if
>> you |set logscale y| in gnuplot. A true logscale mapping is fully determined 
>> by
>> two points, a center is not necessary. Here is how that would compare to the
>> function you implemented:
>>
>> |begin=32.7; end=8372; center=523; e=log((end-begin) / (center-begin)) / 
>> log(2)
>> print e; set logscale y; plot [0:1] begin + x**e * (end-begin), center, exp 
>> (log
>> (begin) + x * (log (end) - log (begin))) |
>>
>> You can also see that this is not true logscale in BlepSynth frequency knob. 
>> It
>> has more pixels for 20..40 Hz than it has for 12000..24000 Hz, even though 
>> what
>> we wanted is that each octave takes the same number of pixels.
>>
>> —
>> You are receiving this because you are subscribed to this thread.
>> Reply to this email directly, view it on GitHub
>> <https://github.com/tim-janik/beast/issues/5#issuecomment-657496751>, or
>> unsubscribe
>>
> <https://github.com/notifications/unsubscribe-auth/AIVS7XUQDYAS5PXL5HX6MTTR3LT5BANCNFSM4DLGVKSA>.
> 
> 


-- 
Stefan Westerfeld, http://space.twc.de/~stefan
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] BLEP based oscillator (rebase) (#29)

[Stefan Westerfeld via beast]

Yes, the main code is merged. There are a few files in this branch but I'll 
merge them in one of the next iterations of BlepSynth.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/29#issuecomment-657529310___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] BLEP based oscillator (rebase) (#29)

[Stefan Westerfeld via beast]

Closed #29.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/29#event-3539262435___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Feature Request: support portamento and logscale parameters (#5)

[Stefan Westerfeld via beast]

> I have just added logscale mappings

The mappings you added are obviously useful, especially for milliseconds (x^3) 
mappings, but these are *not logscale*. A true logscale mapping plots as line 
if you `set logscale y` in gnuplot. A true logscale mapping is fully determined 
by two points, a center is not necessary. Here is how that would compare to the 
function you implemented:
```
begin=32.7; end=8372; center=523; e=log((end-begin) / (center-begin)) / log(2)
print e; set logscale y; plot [0:1] begin + x**e * (end-begin), center, exp 
(log (begin) + x * (log (end) - log (begin)))
```
You can also see that this is not true logscale in BlepSynth frequency knob. It 
has more pixels for 20..40 Hz than it has for 12000..24000 Hz, even though what 
we wanted is that each octave takes the same number of pixels.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/issues/5#issuecomment-657496751___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] BlepSynth initial implementation (#142)

[Stefan Westerfeld via beast]

Btw, one issue I ran into while testing was that the project auto deactivation 
was triggered. So to be able to test, I disabled the function auto_deactivate 
in bseproject.cc.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/142#issuecomment-653807030___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] BlepSynth initial implementation (#142)

[Stefan Westerfeld via beast]

So here is the first version of my BlepSynth subtractive synth. Its 
based on MinBLEP oscillators and a non-linear Moog VCF (LadderVCF). Obviously 
this is the initial version and there is still plenty of thing to do, I have 
put some TODO comments in the code. Once the midi API is available, it should 
be easy to add it to the code.

I am not sure if the cc/hh files live in the right place and are integrated 
properly. Also missing are the programs I use for testing/development. Two 
examples:
- designblep.cc is used to design the blep that is stored an data in a cc file
- testblep.cc is used for testing the blep oscillator

So either I should maintain them independently (out of the beast tree), or it 
should be added to the beast tree. The old bleposc branch had the tools 
included.

As for stuff to add, besides exporting some more properties, an ADSR for the 
filter would improve the stuff you can do with it. The next big addition then 
would be LFOs for the parameters to be able to use the possibilties provided by 
the code which was written with per-sample modulation.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/142

-- Commit Summary --

  * BSE: blepsynth.cc: started to implement BlepSynth processor
  * BSE: blepsynth.cc: add ADSR volume envelope
  * BSE: BlepSynth: added real blep oscillators
  * BSE: blepsynth.cc: add osc unison properties
  * BSE: blepsynth.cc: add more oscillator properties
  * BSE: blepsynth.cc: add lowpass filter
  * BSE: blepsynth.cc: support different midi channels

-- File Changes --

M bse/Makefile.mk (4)
A bse/bleposc.hh (723)
A bse/bleposcdata.cc (837)
A bse/blepsynth.cc (530)
A bse/laddervcf.hh (338)

-- Patch Links --

https://github.com/tim-janik/beast/pull/142.patch
https://github.com/tim-janik/beast/pull/142.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/142
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] TESTS: testresampler: fix resampler tests for clang9 (#140)

[Stefan Westerfeld via beast]

As additional information, g++-8 also generates different code if you use -mfma.
```
$ out/tests/suite1 --resampler accuracy --fpu --precision=24 --subsample 
--freq-scan=90,9000,983 --freq-scan-verbose --verbose

## g++ 8.3.0 without fma

# accuracy test for factor 2 subsampling using FPU instructions
#   input frequency range used [ 90.00 Hz, 9000.00 Hz ] (SR = 44100.0 Hz, freq 
increment = 983.00)
90.0 -129.40792803150048940
1073.0 -130.14152510098830362
2056.0 -131.64395956575623359
3039.0 -131.48377752074048885
4022.0 -127.52623479658792860
5005.0 -131.74602243860934436
5988.0 -131.71784952867952256
6971.0 -133.09696883539237433
7954.0 -131.53986659892970579
8937.0 -131.78909542900839824
#   max difference between correct and computed output: 0.00 = -127.526235 
dB

## g++ 8.3.0 with fma

# accuracy test for factor 2 subsampling using FPU instructions
#   input frequency range used [ 90.00 Hz, 9000.00 Hz ] (SR = 44100.0 Hz, freq 
increment = 983.00)
90.0 -129.82104550124302023
1073.0 -131.03707434810391419
2056.0 -132.40996614732904391
3039.0 -133.12443453736065635
4022.0 -129.32954166513573568
5005.0 -131.90536134591866357
5988.0 -130.93045250711062977
6971.0 -132.01135805265508338
7954.0 -132.97021680274394839
8937.0 -133.11067142912733630
#   max difference between correct and computed output: 0.00 = -129.329542 
dB
```

So (unlike clang9), the fma version provides slightly more accurate results for 
our 4022 Hz sine wave.

My mental model is this: we start from the error the filter gives us under 
perfect conditions (infinite precision coefficients and arithmetic). Then we 
add some random error (with some distribution) that depends on the type and 
order of the instructions generated by the compiler, due to finite precision. 
From everything I saw, both clang9 and g++ 8.3.0 provide valid translations 
with and without -mfma.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/140#issuecomment-598647103___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] TESTS: testresampler: fix resampler tests for clang9 (#140)

[Stefan Westerfeld via beast]

> Did you find out _why_ this is needed?
> I.e. peeked at the generated assembly to figure if -ffast-math related 
> options possibly allow transformations that could become problematic for us 
> in the long term?

**Short answer:**
I spent some time debugging it, -mfma is causing this - removing the flag gives 
us the old behaviour, clang does use fused multiply add instructions in the 
inner loop of the resampler. I don't believe that this optimization has 
negative impact for us, so adjusting the threshold is the sane thing to do here.

**Long answer:**

Lets first look at what exactly is failing here. We have (in explicit form):
```
$ out/tests/suite1 --resampler accuracy --fpu --precision=24 --subsample 
--freq-scan=90,9000,983 --freq-scan-verbose --verbose

## clang9 without fma

# accuracy test for factor 2 subsampling using FPU instructions
#   input frequency range used [ 90.00 Hz, 9000.00 Hz ] (SR = 44100.0 Hz, freq 
increment = 983.00)
90.0 -129.45954766716391759
1073.0 -130.16677118621706200
2056.0 -129.70751203525446726
3039.0 -132.36528831269109219
4022.0 -128.39849621726884266
5005.0 -128.95512230052295877
5988.0 -131.49506213647262598
6971.0 -131.66641240173382243
7954.0 -131.26927901299603718
8937.0 -134.06944494072371299
#   max difference between correct and computed output: 0.00 = -128.398496 
dB

## clang9 with fma

# accuracy test for factor 2 subsampling using FPU instructions
#   input frequency range used [ 90.00 Hz, 9000.00 Hz ] (SR = 44100.0 Hz, freq 
increment = 983.00)
90.0 -129.87588683579858184
1073.0 -126.11881934685534645
2056.0 -128.02398873831205606
3039.0 -128.56669380739046460
4022.0 -124.92935085933235939
5005.0 -128.10076816664792432
5988.0 -128.49709000891502342
6971.0 -127.39047422816582866
7954.0 -127.65962334132801459
8937.0 -130.40537251311835121
#   max difference between correct and computed output: 0.01 = -124.929351 
dB
```

So we're testing 24 bit downsampling followed by upsampling with FPU 
instructions here. Using a 4022 Hz sine wave performs worse with fma. Note that 
24 bit is the most problematic test we have, since the accuracy of the floating 
point computations is not really good enough to reliably evaluate the 
convolution of the large FIR filter. Anyway if we look at the source and 
assembly of the FPU code, we'll see the difference:

**Source Code:**
```
template static inline Accumulator
fir_process_one_sample (const float *input,
const float *taps, /* [0..order-1] */
const uint   order)
{
  Accumulator out = 0;
  for (uint i = 0; i < order; i++)
out += input[i] * taps[i];
  return out;
}
```
Both assembly dumps use loop unrolling, so I'm truncating the assembly code. 
Also I only show the upsampling step here, but downsampling looks the same.

**Code generated with clang9 & -mfma**
```
 ::process_sample_unaligned(float const*, float*)>:
   0:   48 8b 47 08 mov0x8(%rdi),%rax
   4:   c5 fa 10 06 vmovss (%rsi),%xmm0
   8:   c5 fa 10 4e 04  vmovss 0x4(%rsi),%xmm1
   d:   c5 f2 59 48 04  vmulss 0x4(%rax),%xmm1,%xmm1
  12:   c4 e2 79 b9 08  vfmadd231ss (%rax),%xmm0,%xmm1
  17:   c5 fa 10 46 08  vmovss 0x8(%rsi),%xmm0
  1c:   c4 e2 71 99 40 08   vfmadd132ss 0x8(%rax),%xmm1,%xmm0
  22:   c5 fa 10 4e 0c  vmovss 0xc(%rsi),%xmm1
  27:   c4 e2 79 99 48 0c   vfmadd132ss 0xc(%rax),%xmm0,%xmm1
  2d:   c5 fa 10 46 10  vmovss 0x10(%rsi),%xmm0
  32:   c4 e2 71 99 40 10   vfmadd132ss 0x10(%rax),%xmm1,%xmm0
  38:   c5 fa 10 4e 14  vmovss 0x14(%rsi),%xmm1
  3d:   c4 e2 79 99 48 14   vfmadd132ss 0x14(%rax),%xmm0,%xmm1
  43:   c5 fa 10 46 18  vmovss 0x18(%rsi),%xmm0
  48:   c4 e2 71 99 40 18   vfmadd132ss 0x18(%rax),%xmm1,%xmm0
...
```
**Code generated with clang9 without -mfma**
```
 6204 
 6205  ::process_sample_unaligned(float const*, float*)>:
 62060:   48 8b 47 08 mov0x8(%rdi),%rax
 62074:   c5 fa 10 06 vmovss (%rsi),%xmm0
 62088:   c5 fa 10 4e 04  vmovss 0x4(%rsi),%xmm1
 6209d:   c5 fa 59 00 vmulss (%rax),%xmm0,%xmm0
 6210   11:   c5 f2 59 48 04  vmulss 0x4(%rax),%xmm1,%xmm1
 6211   16:   c5 fa 58 c1 vaddss %xmm1,%xmm0,%xmm0
 6212   1a:   c5 fa 10 4e 08  vmovss 0x8(%rsi),%xmm1
 6213   1f:   c5 f2 59 48 08  vmulss 0x8(%rax),%xmm1,%xmm1
 6214   24:   c5 fa 10 56 0c  vmovss 0xc(%rsi),%xmm2
 6215   29:   c5 ea 59 50 0c  vmulss 0xc(%rax),%xmm2,%xmm2
 6216   2e:   c5 f2 58 ca vaddss %xmm2,%xmm1,%xmm1
 

[tim-janik/beast] TESTS: testresampler: fix resampler tests for clang9 (#140)

[Stefan Westerfeld via beast]

Relax expected accuracy for 24-bit subsampling from 126 to 124.5 dB, to fix
testresampler for clang9.

This should fix #139.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/140

-- Commit Summary --

  * TESTS: testresampler: fix resampler tests for clang9

-- File Changes --

M tests/testresampler.cc (2)

-- Patch Links --

https://github.com/tim-janik/beast/pull/140.patch
https://github.com/tim-janik/beast/pull/140.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/140
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

spectmorph-0.5.1

[Stefan Westerfeld via beast]

spectmorph-0.5.1 has been released.

If you haven't watched our video tutorial for the instrument editor
added in 0.5.0, you can do so here: https://youtu.be/JlugWYPDp84

This release introduces statically linked generic 64 bit linux plugin
binaries, so even if the packages don't match your linux version, you
should be able to install these without compiling. This is a new
feature, let me know if it doesn't work for you.

Overview of Changes in spectmorph-0.5.1:

* Add new LFO modes (saw, square, random)
* Support generic 64-bit linux binaries
  - new linux file selector (no longer needs Qt)
  - ship font for static build
* Fix crashes caused by fftw planner being used from multiple threads
* Ported all python2 code to python3
* Support midi all notes off
* Implement LV2 StateChanged
* French translation for smjack desktop file (Olivier Humbert)
* Thread race fix (JP Cimalando)
* Minor fixes and cleanups

What is SpectMorph?
---
SpectMorph is a free software project which allows to analyze samples of
musical instruments, and to combine them (morphing). It can be used to
construct hybrid sounds, for instance a sound between a trumpet and a
flute; or smooth transitions, for instance a sound that starts as a
trumpet and then gradually changes to a flute.

SpectMorph ships with many ready-to-use instruments which can be
combined using morphing.

SpectMorph is implemented in C++ and licensed under the GNU LGPL version 3

Integrating SpectMorph into your Work
-
SpectMorph is currently available for Linux, Windows and macOS users.
Here is a quick overview of how you can make music using SpectMorph.

- VST Plugin, especially for proprietary solutions that don't support LV2.
  (Available on Linux and 64-bit Windows/macOS)
- LV2 Plugin, for any sequencer that supports it.
- JACK Client.

Links:
--
Website:  http://www.spectmorph.org
Download: http://www.spectmorph.org/downloads

There are many audio demos on the website, which demonstrate morphing
between instruments.
-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] TESTS: make time consuming resampler tests run as slow tests (#137)

[Stefan Westerfeld via beast]

I made every resampler test that is somewhat slow run as slow test. This 
reduces the time it takes to execute all resampler tests on my machine from 1.9 
seconds to 0.3 seconds if only one cpu is used. Note that although I added

```
  if (Bse::Test::slow())
```

to execute the resamplehandle benchmarks if and only if were running as 
slow tests, I found that the resamplehandle benchmarks are now never executed 
(which probably doesnt matter). I tried to investigate, 
`Bse::Test::slow()` does something like
```
  static bool cached_slow = feature_toggle_bool (getenv (BSE_TEST), 
slow);
```
but that variable is never set elsewhere in the code (or at least I dont 
find where it is).
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/137

-- Commit Summary --

  * TESTS: make time consuming resampler tests run as slow tests

-- File Changes --

M tests/resamplehandle.cc (12)
M tests/testresamplerq.cc (2)

-- Patch Links --

https://github.com/tim-janik/beast/pull/137.patch
https://github.com/tim-janik/beast/pull/137.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/137
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] TESTS: testresampler: provide more information if accuracy test fails (#136)

[Stefan Westerfeld via beast]

Is this an acceptabe solution for making failed resampler tests report details 
of why the test failed?
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/136

-- Commit Summary --

  * TESTS: testresampler: provide more information if accuracy test fails

-- File Changes --

M tests/testresampler.cc (64)

-- Patch Links --

https://github.com/tim-janik/beast/pull/136.patch
https://github.com/tim-janik/beast/pull/136.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/136
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: Resampler uninitialized value

[Stefan Westerfeld via beast]

   Hi!

Am 27.12.19 um 01:21 schrieb Tim Janik:
> please note this warning in a recent CI run:
> 
>   CXX  out/tests/testresamplerq.o
> tests/testresamplerq.cc:199:20: warning: 1st function call argument is an
> uninitialized value
>   TASSERT (bse_db_from_factor (rt_up.max_error, -200) < -125);
>^~
> ./bse/testing.hh:22:56: note: expanded from macro 'TASSERT'
> #define TASSERT(cond)   TASSERT__AT (__LINE__, cond)///<
> Unconditional test assertion, enters breakpoint if not fullfilled.
>^~~~
> ./bse/testing.hh:115:26: note: expanded from macro 'TASSERT__AT'
>   do { if (BSE_ISLIKELY (cond)) break;  \
>  ^~~~
> ./bse/cxxaux.hh:40:57: note: expanded from macro 'BSE_ISLIKELY'
> #define BSE_ISLIKELY(expr)  __builtin_expect (bool (expr), 1)   ///<
> Compiler hint to optimize for @a expr evaluating to true.
> ^~~~
> 1 warning generated.
> 
> https://travis-ci.org/tim-janik/beast/jobs/629651405
> 
> There are also some fcompare warnings you might want to take a look at.

Right, this was actually helpful input by cppcheck/scan-build: I created
pull requests for the resulting changes, two of the commits are really
bug fixes.

 - https://github.com/tim-janik/beast/pull/134
 - https://github.com/tim-janik/beast/pull/135

   Cu... Stefan
-- 
Stefan Westerfeld, http://space.twc.de/~stefan
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] A few bsefcompare cleanups for cppcheck/scan-build issues (#135)

[Stefan Westerfeld via beast]

The first commit really just cleans up the code as suggested by cppcheck, 
however the second commit fixes an actual bug in the max similarity 
computation, although for almost everybody the fix is irrelevant.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/135

-- Commit Summary --

  * TOOLS: bsefcompare: minor code cleanups as recommended by cppcheck
  * TOOLS: bsefcompare: fix broken maximum calculation (found by scan-build)

-- File Changes --

M tools/bsefcompare.cc (32)

-- Patch Links --

https://github.com/tim-janik/beast/pull/135.patch
https://github.com/tim-janik/beast/pull/135.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/135
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] TESTS: fix testresamplerq checks, make all failed assertions fatal (#134)

[Stefan Westerfeld via beast]

Using assert_return(...) is not good for tests, we want to fail fast if 
something goes wrong.

Signed-off-by: Stefan Westerfeld ste...@space.twc.de
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/134

-- Commit Summary --

  * TESTS: fix testresamplerq checks, make all failed assertions fatal

-- File Changes --

M tests/testresamplerq.cc (4)

-- Patch Links --

https://github.com/tim-janik/beast/pull/134.patch
https://github.com/tim-janik/beast/pull/134.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/134
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] BSE: Jack: add midi driver (#129)

[Stefan Westerfeld via beast]

I believe this is now ready for merging. The midi driver has has the 
improvements we talked about:
* both audio and midi driver now support open without auto connect (using 
"no-auto-connect" devid)
* the "no-auto-connect" [audio|midi] device can be selected in the ebeast 
preferences dialog 
* there is now a 1:N relationship between audio and midi driver, i.e. you can 
open more than one midi devid at a time

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/129#issuecomment-539053052___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] BSE: Jack: add midi driver (#129)

[Stefan Westerfeld via beast]

@swesterfeld pushed 2 commits.

616ace2965d53e54721dd3b3d1f6a49045d085fb  BSE: Jack: support opening more than 
one jack driver
bba08488dd5331317f314ba924823a25bf04ba90  DOCS: updated jack midi howto


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/tim-janik/beast/pull/129/files/3516b54af9a79d7ab6d316d4e3024c3156e03da6..bba08488dd5331317f314ba924823a25bf04ba90
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] BSE: Jack: add midi driver (#129)

[Stefan Westerfeld via beast]

@swesterfeld pushed 1 commit.

3516b54af9a79d7ab6d316d4e3024c3156e03da6  BSE: Jack: support "no-audio-connect" 
devid for midi and audio drivers


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/tim-janik/beast/pull/129/files/326bcea78f6754228ad516e70413b2bd71eaa24f..3516b54af9a79d7ab6d316d4e3024c3156e03da6
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] BSE: Jack: add midi driver (#129)

[Stefan Westerfeld via beast]

@swesterfeld pushed 1 commit.

5cb66071c26fc8afe77894f540ca10132a2fbd9c  DOCS: add a brief description of how 
to use our jack midi driver


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/tim-janik/beast/pull/129/files/4d72388a85a96d4d4818c05ccaf1056b8bc49fb4..5cb66071c26fc8afe77894f540ca10132a2fbd9c
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] BSE: Jack: add midi driver (#129)

[Stefan Westerfeld via beast]

@swesterfeld pushed 1 commit.

4d72388a85a96d4d4818c05ccaf1056b8bc49fb4  BSE: Jack: allow to disable midi 
driver auto connect


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/tim-janik/beast/pull/129/files/ef4bc69f79e9c4504020dcfc531ec285571855a1..4d72388a85a96d4d4818c05ccaf1056b8bc49fb4
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] BSE: Jack: add midi driver (#129)

[Stefan Westerfeld via beast]

@swesterfeld pushed 1 commit.

ef4bc69f79e9c4504020dcfc531ec285571855a1  BSE: Jack: clean up port names


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/tim-janik/beast/pull/129/files/9ea0e38c7ba8400bba7385ec994ac8aa93eec308..ef4bc69f79e9c4504020dcfc531ec285571855a1
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] BSE: Jack: add midi driver (#129)

[Stefan Westerfeld via beast]

So here is a midi (input) driver for jack. The audio/midi driver share the same 
jack client, I documented the assumptions I have to make for the communication 
of the two in the code. While the audio driver typically only has one option 
(the default audio device), for midi there can be more than one choice. For 
example here is the relevant part of `--bse-driver-list` on my system if I 
configure jackd to do the midi handling - we get one possible device in this 
case:
```
Available MIDI drivers:
  jack=system:midi_capture_1:(Input, 0100)
JACK Midi system:midi_capture_1 [Physical: 
in-hw-2-0-0-UA-25EX-MIDI-1]
Hardware Midi Input
Routing via the JACK Audio Connection Kit
Note: JACK adds latency compared to direct hardware access
```
And the same system using alsa midi bridge setting in cadence (uses a2jmidid):
```
Available MIDI drivers:
  jack=a2j:Midi Through [14] (capture): Midi Through Port-0: (Input, 0100)
JACK Midi a2j:Midi Through [14] (capture): Midi Through 
Port-0
Hardware Midi Input
Routing via the JACK Audio Connection Kit
Note: JACK adds latency compared to direct hardware access
  jack=a2j:UA-25EX [24] (capture): UA-25EX MIDI 1: (Input, 0101)
JACK Midi a2j:UA-25EX [24] (capture): UA-25EX MIDI 1
Hardware Midi Input
Routing via the JACK Audio Connection Kit
Note: JACK adds latency compared to direct hardware access
```
So here we get more than one device entry, and if there were more midi devices 
we would get even more. In this case we have relatively long device names, but 
we need both: client name and port name to distinguish between devices.

I also added a comment about auto connect which should really be configurable 
one day; still even without that the midi driver should be usable.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/129

-- Commit Summary --

  * BSE: Jack: add midi driver

-- File Changes --

M bse/driver-jack.cc (233)

-- Patch Links --

https://github.com/tim-janik/beast/pull/129.patch
https://github.com/tim-janik/beast/pull/129.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/129
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Jack driver new api (#128)

[Stefan Westerfeld via beast]

@swesterfeld pushed 1 commit.

a96049760b7b37bc643b6063782203911a2d4b87  BSE: Jack: some minor fixes as 
requested in review


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/tim-janik/beast/pull/128/files/f0c4879177cd50959242cfacc4fd8e5b3288ce14..a96049760b7b37bc643b6063782203911a2d4b87
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Jack driver new api (#128)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> +  std::atomic  atomic_active_ {0};
+  std::atomic  atomic_xruns_ {0};
+  int   printed_xruns_ = 0;
+
+  bool  is_down_ = false;
+  bool  printed_is_down_ = false;
+
+  uint64device_read_counter_ = 0;
+  uint64device_write_counter_ = 0;
+  int   device_open_counter_ = 0;
+
+  static int
+  static_process_callback (jack_nframes_t   n_frames,
+   void*jack_handle)
+  {
+return static_cast  (jack_handle)->process_callback 
(n_frames);

Done.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/128#discussion_r326871556___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Jack driver new api (#128)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> +  jack_port_set_latency_range (port, mode, );
+  }
+else
+  {
+jack_latency_range_t range = get_latency_for_ports (output_ports_, 
mode);
+range.min += buffer_frames_;
+range.max += buffer_frames_;
+
+for (auto port : input_ports_)
+  jack_port_set_latency_range (port, mode, );
+  }
+  }
+  static void
+  static_shutdown_callback (void *jack_handle)
+  {
+static_cast (jack_handle)->shutdown_callback();

Done.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/128#discussion_r326871565___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Jack driver new api (#128)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> +
+if (!p) // first port
+  range = port_range;
+else
+  {
+range.min = std::min (range.min, port_range.min);
+range.max = std::max (range.max, port_range.max);
+  }
+  }
+return range;
+  }
+  static void
+  static_latency_callback (jack_latency_callback_mode_t  mode,
+   void *jack_handle)
+  {
+static_cast  (jack_handle)->latency_callback (mode);

Done.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/128#discussion_r326871561___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Jack driver new api (#128)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> + * implemented by two index variables (read_frame_pos and write_frame_pos)
+ * for which atomic integer reads and writes are required. Since the
+ * producer thread only modifies the write_frame_pos and the consumer thread
+ * only modifies the read_frame_pos, no compare-and-swap or similar
+ * operations are needed to avoid concurrent writes.
+ */
+template
+class FrameRingBuffer {
+  //BIRNET_PRIVATE_COPY (FrameRingBuffer);
+private:
+  vector >  channel_buffer_;
+  std::atomicatomic_read_frame_pos_;
+  std::atomicatomic_write_frame_pos_;
+  uintchannel_buffer_size_;   // = n_frames + 1; the extra 
frame allows us to
+  // see the difference 
between an empty/full ringbuffer
+  uintn_channels_;

Done.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/128#discussion_r326871548___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Jack driver new api (#128)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> +}
+
+static void
+list_jack_drivers (Driver::EntryVec )
+{
+  map devices;
+  jack_client_t *jack_client = connect_jack();
+  if (jack_client)
+{
+  devices = query_jack_devices (jack_client);
+  disconnect_jack (jack_client);
+}
+  else
+{
+  // should we try to generate and show an error message if connecting 
jack failed?
+}

Ok, removed the else branch.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/128#discussion_r326871536___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Jack driver new api (#128)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> +fast_copy (uintn_values,
+   Data   *ovalues,
+  const Data *ivalues)
+{
+  copy (ivalues, ivalues + n_values, ovalues);
+}
+
+template<> void
+fast_copy (uint n_values,
+   float   *ovalues,
+   const float *ivalues)
+{
+  Block::copy (n_values, ovalues, ivalues);
+}
+
+#if 0 // <- avoid unused warning

Done.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/128#discussion_r326871528___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Jack driver new api (#128)

[Stefan Westerfeld via beast]

Ok, last commit should have all the fixes you requested.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/128#issuecomment-533811472___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Jack driver new api (#128)

[Stefan Westerfeld via beast]

@swesterfeld pushed 1 commit.

f0c4879177cd50959242cfacc4fd8e5b3288ce14  BSE: Jack: some minor fixes as 
requested in review


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/tim-janik/beast/pull/128/files/5853ec0cc8dfad08e7fa72e7e758889f12e7b29a..f0c4879177cd50959242cfacc4fd8e5b3288ce14
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Jack driver new api (#128)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> +  }
+
+/* setup PCM handle or shutdown */
+if (error == 0)
+  {
+flags_ |= Flags::OPENED;
+
+uint dummy;
+pcm_latency (, );   // debugging only: print latency values
+  }
+else
+  {
+disconnect_jack (jack_client_);
+jack_client_ = nullptr;
+  }
+JDEBUG ("JACK: opening PCM \"%s\" readupble=%d writable=%d: %s", 
devid_.c_str(), readable(), writable(), bse_error_blurb (error));

Fixed.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/128#discussion_r326865969___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Jack driver new api (#128)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> +
+/* enable processing in callback (if not already active) */
+atomic_active_ = 1;
+
+/* report jack driver xruns */
+if (atomic_xruns_ != printed_xruns_)
+  {
+printed_xruns_ = atomic_xruns_;
+Bse::printerr ("JACK: %d beast driver xruns\n", printed_xruns_);
+  }
+/* report jack shutdown */
+if (is_down_ && !printed_is_down_)
+  {
+printed_is_down_ = true;
+Bse::printerr ("JACK: connection to jack server lost\n");
+Bse::printerr ("JACK:  -> to continue, manually stop playback and 
restart\n");

Fixed.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/128#discussion_r326865973___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Jack driver new api (#128)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> +  void
+  shutdown_callback()
+  {
+is_down_ = true;
+  }
+public:
+  explicit  JackPcmDriver (const String ) : PcmDriver (devid) {}
+  static PcmDriverP
+  create (const String )
+  {
+auto pdriverp = std::make_shared (devid);
+return pdriverp;
+  }
+  ~JackPcmDriver()
+  {
+  }

Right. Fixed.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/128#discussion_r326865465___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Jack driver new api (#128)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> +vector silence_buffers 
> (output_ringbuffer_.get_n_channels());
+
+fill (silence_buffers.begin(), silence_buffers.end(), [0]);
+
+uint frames_written = output_ringbuffer_.write (buffer_frames, 
_buffers[0]);
+if (frames_written != buffer_frames)
+  Bse::warning ("JACK driver: output silence init failed: 
(frames_written != jack->buffer_frames)\n");
+
+  }
+
+/* activate */
+if (error == 0)
+  {
+jack_set_process_callback (jack_client_, static_process_callback, 
this);
+jack_set_latency_callback (jack_client_, static_latency_callback, 
this);
+jack_on_shutdown (jack_client_, static_shutdown_callback, this);

Fixed. Interesting, didn't know that this would work.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/128#discussion_r326865341___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Jack driver new api (#128)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> +  /* the default device is usually the hardware device, so things should 
> work as expected
+   * we could show try to show non-default devices as well, but this could 
be confusing
+   */
+  if (details.default_device)
+{
+  Driver::Entry entry;
+  entry.devid = device_name;
+  entry.priority = Driver::JACK;
+  entries.push_back (entry);
+}
+}
+}
+
+/* macro for jack dropout tests - see below */
+#define TEST_DROPOUT() if (unlink ("/tmp/drop") == 0) usleep (1.5 * 100. * 
buffer_frames_ / mix_freq_); /* sleep 1.5 * buffer size */
+

Ok, done.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/128#discussion_r326864743___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] Jack driver new api (#128)

[Stefan Westerfeld via beast]

Ok, here is a port of the Jack driver 
(https://github.com/tim-janik/beast/pull/31) to the new driver API. I tested 
playback and also stereo-through. This doesnt yet have midi support.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/128

-- Commit Summary --

  * BUILD: require jack
  * BSE: Jack: initial version of Jack driver using the new driver API
  * DOCS: add minimal jack howto
  * BSE: bsemain.cc: block SIGPIPE to avoid crashes when jackd dies
  * BSE: Driver: return read and write latency for a pcm driver separately
  * BSE: Jack: add list with possible improvements from PR#31.

-- File Changes --

M bse/Makefile.mk (1)
M bse/bsemain.cc (16)
M bse/driver-alsa.cc (7)
A bse/driver-jack.cc (905)
M bse/driver.cc (8)
M bse/driver.hh (2)
M config-checks.mk (3)
A docs/howto-jack.md (55)

-- Patch Links --

https://github.com/tim-janik/beast/pull/128.patch
https://github.com/tim-janik/beast/pull/128.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/128
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] BSE: driver-alsa.cc: fix buffer for pcm writes during retrigger, fixes #127 (644460e)

[Stefan Westerfeld via beast]

This could break if n_channels_ is large (24 or something).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/commit/644460eb0ec5aea103eec2d85b919624fdb2cedf#commitcomment-35169320___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Ladder Filter (#122)

[Stefan Westerfeld via beast]

@swesterfeld pushed 1 commit.

14ffd216b25d36e31a1597a05dd297b66f89baba  PLUGINS: LadderFilter: port code to 
new Resampler2 API


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/tim-janik/beast/pull/122/files/e99219227900340fa8ee06cb9fb4a2e2b8e3fa95..14ffd216b25d36e31a1597a05dd297b66f89baba
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] BSE: driver-alsa.cc: fix crash in retrigger code (#127)

[Stefan Westerfeld via beast]

I was playing a bit with the new alsa driver, and I found that for my first hw 
device, it crashed like this:

```
stefan@quadcorn:~/src/3rd-tree/ghbeast (master *% u=)$ LANG=C beast
beast: unable to acquire soft realtime priority: Permission denied
beast-0.15.0: bse/bseengineutils.cc:632: bse_engine_const_zeros: assertion 
failed: smaller_than_BSE_STREAM_MAX_VALUES = (1024 )
beast-0.15.0: pcm.c:1424: snd_pcm_writei: Assertion `size == 0 || buffer 
failed.
```

The problem is that bseengineutils.cc imposes a limit on how big a const zeros 
float block can be, and on my device, the amount of zero data for the retrigger 
was larger than 1024 floats, so the driver ended up trying to write a null 
pointer.

I fixed this crash, and I think I also found another mistake here: n_channels 
was not taken into account by your original code (buffer_length / 2 would be 
wrong), so in the fixed version it uses n_channels * sizeof (int16) bytes per 
frame.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/127

-- Commit Summary --

  * BSE: driver-alsa.cc: fix crash in retrigger code

-- File Changes --

M bse/driver-alsa.cc (3)

-- Patch Links --

https://github.com/tim-janik/beast/pull/127.patch
https://github.com/tim-janik/beast/pull/127.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/127
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Resampler cleanups (#125)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> @@ -188,6 +188,12 @@ main (int argc, char *argv[])
   bench_aida();
   return 0;
 }
+  if (argc >= 2 && argv[1] && std::string ("--resampler") == argv[1])
+{
+  Bse::init_async (, argv, argv[0], args);
+  extern int test_resampler (int, char **);

OK, should be fixed once you merge https://github.com/tim-janik/beast/pull/126

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/125#discussion_r325072198___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] TESTS: testresampler: add header file for test_resampler prototype (#126)

[Stefan Westerfeld via beast]

As requested in PR https://github.com/tim-janik/beast/pull/125.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/126

-- Commit Summary --

  * TESTS: testresampler: add header file for test_resampler prototype

-- File Changes --

M tests/suite1-main.cc (14)
M tests/testresampler.cc (3)
A tests/testresampler.hh (7)

-- Patch Links --

https://github.com/tim-janik/beast/pull/126.patch
https://github.com/tim-janik/beast/pull/126.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/126
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Resampler cleanups (#125)

[Stefan Westerfeld via beast]

@swesterfeld pushed 1 commit.

0e14df11e638c164177b98d00ef34a7d1a08f02f  BSE: Resampler2: fix compilation with 
clang


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/tim-janik/beast/pull/125/files/55e5fe36fce9a874e5a9a262433eeef24c5cebba..0e14df11e638c164177b98d00ef34a7d1a08f02f
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Resampler cleanups (#125)

[Stefan Westerfeld via beast]

Since this PR wasn't merged yet, I simply force pushed an updated version. 
Since we have no more C API, I could modernize the C++ API. It should be used 
like this:
```
  float input[128];
  float output[256];
  Resampler2 resampler (Resampler2::UP, Resampler2::PREC_96DB);
  resampler.process_block (input, 128, output);
```
Note that process_block() still needs a virtual function call (like it used to 
be), but I did some benchmarking before refactoring the API. The performance 
difference between virtual function call and inlined resampler code is minimal. 
Like this, I could move all implementation bits back into `bseresampler.cc`, so 
`bseresampler.hh` is really clean and doesn't contain any actual resampling 
code, and `bseresamplerimpl.hh` could be removed.

I also re-added the old testresampler tests from the Makefile.am, these are 
added using TEST_SLOW, so `out/tests/suite1 --slow` is needed to run the tests. 
I also re-enabled the standalone testcode, passing args to the standalone 
main() from suite1 main()
```
$ testresampler perf # OLD
$ out/tests/suite1 --resampler perf # NEW
```
Btw, if you are interested in the impact of the block size on performance, here 
is upsampling with different block sizes (times in ns/sample) upsampling, 
PREC48_DB.
```
4 5.1589
8 3.52419
16 3.80419
32 3.079
64 2.48795
128 2.25006
256 2.09908
512 2.019
```

I recommend merging this PR first, then I can update the LadderFilter PR 
(https://github.com/tim-janik/beast/pull/122) to use the new resampling API, 
then merge the LadderFilter.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/125#issuecomment-531581129___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Resampler cleanups (#125)

[Stefan Westerfeld via beast]

@swesterfeld pushed 23 commits.

1c10aadd20aadf8412cdcc78d3af3bda304f6e00  BSE: Resampler: remove C API
8980aaafd5755f1413f5d9d0f48845de85111a4b  TESTS: resamplehandle: remove 
Resampler C API test
a9962f8acd512896d02cf1908c7e101102a9343c  BSE: no longer rely on block utils to 
create Resampler2 implementation
4bc68a800b1ca518d3e172520c2e60ff526ad49b  TESTS: no longer rely on block utils 
to create Resampler2 implementation
3d79f91bc20b6f93eee80cd742fcace86a23d63d  BSE: Resampler2: properly support SSE 
again
0bd208dc4cd793b3696afeae303855d9d3571f12  TESTS: testresamplerq: re-enable SSE 
tests (and still do FPU tests)
d6f3998c2f8ad4a12f822e02cbb1f89d87a3f3b3  TESTS: resamplehandle: test both: 
SSE/FPU version for delay compensation
ae609d9ebf3494a34307c785f145e722719101f4  TESTS: testresampler: re-enable tests 
for both: SSE and FPU Resampler
15d473054ec3f64dd3d4bd2afcec55c85c04457d  TOOLS: bsewavetool: remove unused 
resampler include
fa5aac074d835a3fdc121eab87bc5f9f362c964a  BSE: Resampler2: small performance 
optimization for downsampler
5bdd9439997efc5841427e92ed95fb7c3be52d1a  BSE: Resampler2: improve C++ API to 
get rid of Resampler2::create
7032bf4473bd48ed6c933d4d46a97996fd824ed1  TESTS: get rid of Resampler2::create
b8dc3ea51b3f73e809f5c8b547d472cc10cce29c  BSE: Resampler2: remove 
Resampler2::create
1bb9b8372aedfd2b076955774ef72b21c41dbf04  TESTS: testresampler: avoid including 
bse/bseresamplerimpl.hh
6eb9fe6fc136b821b2f0a94ff4c4c39d33cbed7c  BSE: Resampler2: merge 
bseresamplerimpl.hh into bseresampler.cc
20b7364ebf9591713bf5a8000994b4007ae8031b  BSE: Resampler2: namespace/enum 
cleanups
6428ae2b63761268d68f54b9f99b9132db3af8e7  TESTS: adapt Resampler2 tests 
(namespace, enums)
4f0c9ea9bb2f789ecf8191eb7b42522fb012c7c6  TESTS: testresampler: use 
AlignedArray instead of F4Vector for alignment
e53b1b5bd9090002bb35a1ce06d43fd1fe861e90  TESTS: testresampler: re-enable 
standalone tests via suite1
0fec4b7e192a9979750995dc87a1c597bb1607b7  TESTS: testresampler: make perf test 
more reliable for small block sizes
f9f28da319f66facc03af1b4c854bf4a4e2e4a8a  TESTS: testresampler: improve 
accuracy test coverage as slow test
4f8e9166286a589fd8d7d87c8b49a2fe8cf3440f  BSE: Resampler2: mark impl classes as 
final
55e5fe36fce9a874e5a9a262433eeef24c5cebba  config-uname.mk: fix x86_64 specific 
build flags


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/tim-janik/beast/pull/125/files/bee9d0ccd3e6047231d6076c306007d2f44c136d..55e5fe36fce9a874e5a9a262433eeef24c5cebba
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Resampler cleanups (#125)

[Stefan Westerfeld via beast]

@swesterfeld pushed 1 commit.

bee9d0ccd3e6047231d6076c306007d2f44c136d  TOOLS: bsewavetool: remove unused 
resampler include


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/tim-janik/beast/pull/125/files/35a300d859f7ab864ff21d51ac0df55c38288239..bee9d0ccd3e6047231d6076c306007d2f44c136d
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Force alsa default device (#123)

[Stefan Westerfeld via beast]

Ok, first of all, I no longer think that changing the auto-detect order for 
devices can solve our problem. As I understand it for, you
- have a duplex (non-default) device you want beast to use
- have a alsa non-duplex default device that you don't want beast to use

On the other hand, I
- have a duplex device I don't want beast to use
- have a alsa non-duplex default device (pulse) I want beast to use

So it seems to me that this cannot be automatically be resolved (so the patch 
here cannot be improved to a state where it works out of the box for both of 
us).

So we need explicit driver selection in the future. So eventually we will need 
.bserc to have an entry for setting the audio driver. I can understand that 
adapting beast-gtk may not be what we want to do, since it makes not much sense 
to invest time in legacy ui code. I can also understand that adapting ebeast 
may not yet be what we want to do, because it may need more time to develop 
ebeast until it is time to add a configuration dialog. But that will happen 
eventually.

So I suggest adding a .bserc option for selecting the driver, so that at least 
I can test ebeast, and in the future the configuration dialog can make this 
meaningful for average users.

And we need not necessarily solve the drift compensation issue before we even 
have a usable ebeast ui that would benefit from it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/123#issuecomment-530792486___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] Resampler cleanups (#125)

[Stefan Westerfeld via beast]

I cleaned up the resampling code:
* the C API was removed
* the implementation no longer relies on blockutils, but does its own SSE/FPU 
handling
* Resampler2::create() got an additional argument: true means SSE should be 
used if available; false means the FPU version should always be used
* FPU/SSE resampling is now under test again, I adapted some of the tests

Plugins (LadderFilter) for now can use Resampler2::create (..., false) to force 
using FPU resampling. As soon as the engine guarantees SSE-alignment of 
input/output blocks, this can be removed.

The old Makefile.am had more testresampler style tests, these could 
be added.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/125

-- Commit Summary --

  * BSE: Resampler: remove C API
  * TESTS: resamplehandle: remove Resampler C API test
  * BSE: no longer rely on block utils to create Resampler2 implementation
  * TESTS: no longer rely on block utils to create Resampler2 implementation
  * BSE: Resampler2: properly support SSE again
  * TESTS: testresamplerq: re-enable SSE tests (and still do FPU tests)
  * TESTS: resamplehandle: test both: SSE/FPU version for delay compensation
  * TESTS: testresampler: re-enable tests for both: SSE and FPU Resampler

-- File Changes --

M bse/bseblockutils.cc (25)
M bse/bseblockutils.hh (14)
M bse/bseresampler.cc (86)
M bse/bseresampler.hh (34)
M bse/bseresamplerimpl.hh (14)
M tests/resamplehandle.cc (55)
M tests/testresampler.cc (92)
M tests/testresamplerq.cc (36)

-- Patch Links --

https://github.com/tim-janik/beast/pull/125.patch
https://github.com/tim-janik/beast/pull/125.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/125
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] BSE: bsemathsignal: add approximations: Bse::fast_log2 and Bse::fast_exp2 (#124)

[Stefan Westerfeld via beast]

Inserting T=float casts makes the function perform better (at least here). It 
avoids conversions between single precision and double precision values (i.e. 
cvtsd2ss) which would otherwise be used. So this version
```
static inline float G_GNUC_CONST
fast_log2ff (float value)
{
  union {
float f;
int i;
  } float_u;
  float_u.f = value;
  // compute log_2 using float exponent
  const int log_2 = ((float_u.i >> 23) & 255) - 128;
  // replace float exponent
  float_u.i &= ~(255 << 23);
  float_u.i += BSE_FLOAT_BIAS << 23;
  typedef float T;
  T u, x = float_u.f;
  // lolremez --long-double -d 6 -r 1:2 "log(x)/log(2)+1-0.0184568668708"
  u = T (-2.5691088815846393966e-2l);
  u = u * x + T (2.7514877034856806734e-1l);
  u = u * x + T (-1.2669182593669424748l);
  u = u * x + T (3.2865287704176774059l);
  u = u * x + T (-5.3419892025067624343l);
  u = u * x + T (6.1129631283200211528l);
  x = u * x + T (-2.040042118396715321l);
  return x + log_2;
}
```
is faster, because all operations are on floats. This costs a bit of precision 
but the float version (`fast_log2ff`) is faster than using double 
(`fast_log2fd`) or long double (`fast_log2fl`).
```
$ g++ -std=c++17 -Wall -g -O3 -o l2 l2.cc `pkg-config --cflags --libs 
spectmorph glib-2.0 bse`
$ l2
log2f: 5.369997 ns/call
fast_log2fl: 7.890487 ns/call
fast_log2fd: 4.662395 ns/call
fast_log2ff: 3.652096 ns/call

prec: fast_log2ff: 4.493532e-06
prec: fast_log2fd: 3.721012e-06
prec: fast_log2fl: 3.691373e-06


$ clang++ -std=c++17 -g -O3 -o l2 l2.cc `pkg-config --cflags --libs spectmorph 
glib-2.0 bse`
$ l2
log2f: 5.323792 ns/call
fast_log2fl: 7.597113 ns/call
fast_log2fd: 5.201006 ns/call
fast_log2ff: 4.071403 ns/call

prec: fast_log2ff: 4.493532e-06
prec: fast_log2fd: 3.721012e-06
prec: fast_log2fl: 3.691373e-06
```

On the other stuff I mostly agree. If you have use cases in mind (for key 
tracking or filter frequency modulation it doesn't matter) that need integers k 
exp2 (k) to be 2^k and you think you want to pay for it with one add-mul, ok. I 
think relative error is the most important goal here, though. For instance if 
the key tracking algorithm returns 222 instead of 220, from a muscians point it 
is as bad as returning 888 instead of 880. Both sound equally wrong, and both 
have the same relative error (not absolute error).

Applying corrections for fast_log2 (2^k) to yield k  for integer k sounds ok to 
me. Note that it doesn't fix fast_log2 (7.99) to be 3, as you patched only 
the case where the input is equal to or slightly greater than 2^k, not the case 
where it is slightly smaller.

```
fast_log2fl (7.99) = 2.96; log2f (7.99) = 3.00
fast_log2fl (8.00) = 3.00; log2f (8.00) = 3.00
fast_log2fl (8.01) = 3.00; log2f (8.01) = 3.00
```
This could be fixed by adjusting the linear coeffcient of the remez polynomial, 
but this would make our worst case error larger, and I think as the result is 
so close to the perfect value it is probably not worth it. 

As for whether to approximate at all on AMD64: my impression from the 
benchmarks is that in many cases using one of the approximations would yield 
sufficient quality faster that exp2f or log2f. On AMD64 especially when using 
T=float internally.

However, the gain is not dramatic, and maybe we're trying to optimize something 
with approximations that is not really a performance problem. For instance the 
LadderFilter (the place where this started) typically only needs one log2 value 
per note-on. Only portamento would affect this negatively which we do not 
support at the moment. What I'm trying to say here is: if we use log2f/exp2f 
and one day we run perf on beast and see than 10% of the CPU usage is spent in 
exp2f, we could still deal with it at that point in time.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/124#issuecomment-530310880___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] BSE: bsemathsignal: add approximations: Bse::fast_log2 and Bse::fast_exp2 (#124)

[Stefan Westerfeld via beast]

First of all, this adds a function that was missing in bsemathsignal: a 
`fast_log2` implementation. It works by using the float exponent and 
approximating the rest of the value using a polynomial. I found a tool that 
gives optimal polynomial coefficients for a given order: 
https://github.com/samhocevar/lolremez

Since I was at it already, I also looked at our exp2 approximations. Comparing 
them to what lolremez would produce, what we do is not ideal. So I also added 
`fast_exp2`. This has consistently better relative errors. So I suggest as next 
step replacing `bse_approxN_exp2` by `fast_exp2N` everywhere, which 
should be as fast, but more accurate. Please review the API and let me know if 
this can be the canonical API for porting the old functions to.

Remarks:
* unlike `bse_approxN_exp2`, our new `fast_exp2N` no longer guarantees 
almost zero error if the argument is an integer; however I think we dont 
really need to preserve this property 
* I like `Bse::fast_log2` better than `Bse::approx_log2` because when reading 
code fast gives me an idea what the function does and why it was 
used instead of log2


Relative `exp2(x)` approximation errors in interval [-1:1]:

```
rxprec: bse_approx2_exp2: 0.009017387
rxprec: bse_approx3_exp2: 0.0007944462
rxprec: bse_approx4_exp2: 5.568432e-05
rxprec: bse_approx5_exp2: 3.24224e-06
rxprec: bse_approx6_exp2: 1.614916e-07
rxprec: bse_approx7_exp2: 7.028907e-09
rxprec: bse_approx8_exp2: 2.716875e-10
rxprec: bse_approx9_exp2: 9.445048e-12

rxprec: fast_exp22, double: 0.001724763
rxprec: fast_exp23, double: 7.478144e-05
rxprec: fast_exp24, double: 2.593371e-06
rxprec: fast_exp25, double: 7.493647e-08
rxprec: fast_exp26, double: 1.8558e-09
rxprec: fast_exp27, double: 4.021119e-11
rxprec: fast_exp28, double: 7.746751e-13
rxprec: fast_exp29, double: 1.375958e-14
```
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/124

-- Commit Summary --

  * BSE: bsemathsignal: add approximations: Bse::fast_log2 and Bse::fast_exp2

-- File Changes --

M bse/bsemathsignal.hh (271)

-- Patch Links --

https://github.com/tim-janik/beast/pull/124.patch
https://github.com/tim-janik/beast/pull/124.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/124
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] Force alsa default device (#123)

[Stefan Westerfeld via beast]

This is a fix for #119 - and finally should make beast work out of the box for 
users which have pulseaudio as default device (for instance together with 
jack/bridging). For me at least this fixes make run.

In order to force using the default device if available, pcm drivers can return 
a string which device is the default device.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/123

-- Commit Summary --

  * BSE: BseDevice: support driver-specific default-device
  * DRIVERS: return driver-specific default device in bsepcmdevice-alsa

-- File Changes --

M bse/bsedevice.cc (9)
M bse/bsedevice.hh (1)
M drivers/bsepcmdevice-alsa.cc (20)

-- Patch Links --

https://github.com/tim-janik/beast/pull/123.patch
https://github.com/tim-janik/beast/pull/123.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/123
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] Ladder Filter (#122)

[Stefan Westerfeld via beast]

This is the implementation of a Moog-style lowpass ladderfilter with saturation 
and 2x oversampling. The number of poles is configurable . Filter modes are 
available for 6db/octave, 12db/octave, 18db/octave and 24db/octave.

I dont have any TODOs left right now, so this could either be the final 
version, or at least fairly close to the final version. Im discarding the 
commit history here, this is not so interesting. The necessary changes for the 
resampler (https://github.com/tim-janik/beast/pull/121) are included in this 
branch.

Right now the resampling is done with the FPU (as plugins/bseblockutils.cc is 
not getting compiled), but that is still fast enough for daily use. Ive 
also noticed that BSE doesnt enforce SSE-alignment of input/output 
buffers, so right now SSE support is broken; if that were fixed, performance 
would be a bit better.

Of course this depends a bit on which inputs/outputs are connected, but for the 
common case one (stereo) ladder filter takes
 * 0.4% CPU usage with FPU resampling
 * 0.33% CPU usage with SSE resampling
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/122

-- Commit Summary --

  * BSE: add Resampler2 function to reset state
  * PLUGINS: add LadderFilter plugin

-- File Changes --

M bse/bseresampler.hh (4)
M bse/bseresamplerimpl.hh (24)
M plugins/Makefile.mk (2)
A plugins/ladderfilter.cc (67)
A plugins/ladderfilter.idl (39)
A plugins/laddervcf.hh (341)

-- Patch Links --

https://github.com/tim-janik/beast/pull/122.patch
https://github.com/tim-janik/beast/pull/122.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/122
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] BSE: add Resampler2 function to reset state (#121)

[Stefan Westerfeld via beast]

Currently, if you want to return a Resampler2 object to its initial state (all 
history values zero), you need to delete the instance and create a new one. 
This adds a reset() function to the API which has the same effect. Im 
using this new API in the Ladder filter implementation.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/121

-- Commit Summary --

  * BSE: add Resampler2 function to reset state

-- File Changes --

M bse/bseresampler.hh (4)
M bse/bseresamplerimpl.hh (24)

-- Patch Links --

https://github.com/tim-janik/beast/pull/121.patch
https://github.com/tim-janik/beast/pull/121.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/121
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] BSE: randomhash.hh: fix compilation on g++ 7.4.0 (#120)

[Stefan Westerfeld via beast]

std::string in C++17 cannot be used at compile time, so constexpr is not 
possible
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/120

-- Commit Summary --

  * BSE: randomhash.hh: fix compilation on g++ 7.4.0

-- File Changes --

M bse/randomhash.hh (2)

-- Patch Links --

https://github.com/tim-janik/beast/pull/120.patch
https://github.com/tim-janik/beast/pull/120.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/120
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] No sound without -p alsa=pulse (#119)

[Stefan Westerfeld via beast]

BEAST for a very long time now refused to produce audio out of the box without 
the command line args `-p alsa=pulse` - I am using  (setup by Cadence)
 - JACK as primary sound server
 - PulseAudio bridged to JACK

Problems have been reported by other users 
(https://github.com/tim-janik/beast/issues/92 
https://github.com/tim-janik/beast/issues/80). Since the new Electron UI 
doesn't have command line args, the workaround cannot be used there, so the new 
UI has no sound.

In order to make this work out-of-the-box: why does the workaround work, 
whereas auto-detected audio output fails?

First of all, it doesn't matter if you use `-p alsa=default` or `-p 
alsa=pulse`. The default device is pulse. So this is the first device the ALSA 
driver tries to open during auto detect. But open fails during auto detect. The 
reason here is that during auto detect, BEAST tries to open the `default` 
device in full duplex mode. Why doesn't this work?

Using printf()s in the alsa pcm driver, I found that although `read_handle` and 
`write_handle` can be opened for `pulse`, the following fails
```
   if (error == 0 && alsa->read_handle && alsa->write_handle &&
   snd_pcm_link (alsa->read_handle, alsa->write_handle) < 0)
 error = Bse::Error::DEVICES_MISMATCH;
```
This was observed already here: 
https://github.com/tim-janik/beast/issues/80#issuecomment-421115474

In any case, the auto detection will try all available devices in duplex mode, 
and settle for some audio device that I don't use - instead of the default 
device - like for instance onboard audio which is not connected.

If I on the other hand specify `-p alsa=pulse`, BEAST will try to open the 
audio output in duplex mode, and fail. Then it will try to open pulseaudio in 
output-only mode, and succeed.

Some ideas how to make it work out-of-the-box:
- adapt alsa driver so that it still works if `snd_pcm_link` fails
- merge JACK driver
- allow explicit driver selection in the UI (effectively allowing users to 
force PulseAudio output)
- force default device if default device is present, even if this has no full 
duplex mode


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/issues/119___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] Server properties ported to C++ (#117)

[Stefan Westerfeld via beast]

This ports all Server properties.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/117

-- Commit Summary --

  * BSE: Server::log_messages: port property to C++
  * BEAST-GTK: bstusermessage: use Server::log_messages C++ property
  * BSE: Server::wave_file: port property to C++
  * BEAST-GTK: bstapp: use Server::wave_file C++ property

-- File Changes --

M beast-gtk/bstapp.cc (9)
M beast-gtk/bstusermessage.cc (2)
M bse/bseapi.idl (7)
M bse/bseserver.cc (64)
M bse/bseserver.hh (6)

-- Patch Links --

https://github.com/tim-janik/beast/pull/117.patch
https://github.com/tim-janik/beast/pull/117.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/117
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] Part properties ported to C++ (#114)

[Stefan Westerfeld via beast]

This is a C++ port of the two Part properties - last_tick and n_channels. I saw 
there is some signal reemission code in bsetrack.cc, seemingly related to 
last_tick updates, which looks like this:
```
bse_object_reemit_signal (part, "notify::last-tick", self, "changed");
...
bse_object_remove_reemit (part, "notify::last-tick", self, "changed");
```
I don't know what a port of this would look like.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/114

-- Commit Summary --

  * BSE: Part::last_tick: port property to C++
  * BEAST-GTK: use Part::last_tick C++ property
  * BSE: Part::n_channels: port property to C++

-- File Changes --

M beast-gtk/bsteventroll.cc (7)
M beast-gtk/bstpatternview.cc (10)
M beast-gtk/bstpatternview.hh (2)
M beast-gtk/bstpianoroll.cc (14)
M beast-gtk/bstpianoroll.hh (2)
M bse/bseapi.idl (5)
M bse/bsepart.cc (86)
M bse/bsepart.hh (5)
M bse/bsetrack.cc (4)

-- Patch Links --

https://github.com/tim-janik/beast/pull/114.patch
https://github.com/tim-janik/beast/pull/114.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/114
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] Properties that have Objects as value are currently not portable to C++ (#113)

[Stefan Westerfeld via beast]

As discussed previously, I created one example what happens if I try to port a 
property that contains an Object to C++. I choose Song postprocessing network 
as example.

```
stefan@quadcorn:~/src/ghbeast (object-pport-error % u=)$ make -j1
  MODE debug
  CHECKConfiguration dependencies...
  GEN  out/config-cache.mk
  KEEP out/config-stamps.sha256
  MODE debug
  GEN  out/bse/bseapi_interfaces.hh out/bse/bseapi_interfaces.cc 
out/bse/bseapi_handles.hh out/bse/bseapi_handles.cc
bse/bseapi.idl:1029: error: invalid type definition: = Object 
(_("Postprocessor"), _("Synthesis network to be used as postprocessor"), 
"r:w:S:G:unprepared")
bse/Makefile.mk:390: recipe for target 
'/.../·out∕bse∕bseapi_interfaces.hh·out∕bse∕bseapi_interfaces.cc·out∕bse∕bseapi_handles.hh·out∕bse∕bseapi_handles.cc·.INTERMEDIATE'
 failed
make: *** 
[/.../·out∕bse∕bseapi_interfaces.hh·out∕bse∕bseapi_interfaces.cc·out∕bse∕bseapi_handles.hh·out∕bse∕bseapi_handles.cc·.INTERMEDIATE]
 Error 7
```

It seems aida doesn't recognize `Object` as valid type here.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/113

-- Commit Summary --

  * BSE: Song::pnet: first steps to port property to C++

-- File Changes --

M bse/bseapi.idl (5)
M bse/bsesong.cc (12)

-- Patch Links --

https://github.com/tim-janik/beast/pull/113.patch
https://github.com/tim-janik/beast/pull/113.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/113
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] Property ports for MidiSynth (#112)

[Stefan Westerfeld via beast]

This ports all properties of the MidiSynth to C++ (except for object properties 
SNet/PNet).

I had to fix a bug in BsePcmOutput (first commit), because setting the volume 
on the output object had no effect, but I wanted to test my code.

To have 1:1 the same ranges, I introduced constants for BSE_MIN|MAX_VOLUME_dB, 
but maybe this should just be hardcoded to -96 / 24. For the new max midi 
channel constant I think a constant should be used (maybe moved up to the other 
constants).

I noticed that some property idl constants don't combine properly. If you write 
Range (... GUI STORAGE ...), this expands to "r:w:G" "r:w:S" - so instead of 
getting a "G" hint, you get a "Gr" hint. Here I used STANDARD as ported 
property type, to work around the issue,which has both "G" and "S" hints. Not 
sure what is intended here, but adding ":" at the beginning and end of each 
property constant would allow using both versions for a GUI & STORAGE property.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/112

-- Commit Summary --

  * BSE: PcmOutput: properly update volume for engine module
  * BSE: MidiSynth::midi_channel: port property to C++
  * BSE: MidiSynth::n_voices: port property to C++
  * BSE: MidiSynth::volume_f: port property to C++
  * BSE: MidiSynth::volume_dB: port property to C++
  * BSE: MidiSynth::volume_perc: port property to C++
  * BSE: MidiSynth: store volume_factor in impl class

-- File Changes --

M bse/bseapi.idl (17)
M bse/bsemidisynth.cc (200)
M bse/bsemidisynth.hh (19)
M bse/bsepcmoutput.cc (34)

-- Patch Links --

https://github.com/tim-janik/beast/pull/112.patch
https://github.com/tim-janik/beast/pull/112.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/112
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] Reproducable crash using MidiSynth midi channel setting (#111)

[Stefan Westerfeld via beast]

1. open menu item "Demo" -> "Midi Test".
2. play
3. hit a few notes on external midi keyboard (produces some sound output)
4. stop
5. change "Midi Test" midi channel to 2
6. play
7. hit a few notes on external midi keyboard -> crash
```
stefan@quadcorn:~/src/beast (master % u=)$ gdb --args 
/usr/local/beast/lib/beast-0-15/bin/beast-0.15.0 -p alsa=pulse
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/beast/lib/beast-0-15/bin/beast-0.15.0...fertig.
(gdb) r
Starting program: /usr/local/beast/lib/beast-0-15/bin/beast-0.15.0 -p alsa=pulse
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffec2f4700 (LWP 28766)]
[New Thread 0x7fffebaf3700 (LWP 28767)]
convolution: samplerate mismatch preset:48000 host:44100
convolution: samplerate mismatch preset:48000 host:44100
convolution: samplerate mismatch preset:48000 host:44100
convolution: samplerate mismatch preset:48000 host:44100
convolution: samplerate mismatch preset:48000 host:44100
convolution: samplerate mismatch preset:48000 host:44100
[New Thread 0x7fffe924d700 (LWP 28768)]
[New Thread 0x7fffe8a4c700 (LWP 28769)]
[New Thread 0x7fffdbfff700 (LWP 28770)]
[Thread 0x7fffdbfff700 (LWP 28770) exited]
[New Thread 0x7fffdbfff700 (LWP 29745)]
[New Thread 0x7fffdaaba700 (LWP 29746)]
[Thread 0x7fffdbfff700 (LWP 29745) exited]
[Thread 0x7fffdaaba700 (LWP 29746) exited]
[New Thread 0x7fffdaaba700 (LWP 29747)]
[New Thread 0x7fffdbfff700 (LWP 29748)]
[New Thread 0x7fffda2b9700 (LWP 29749)]
[New Thread 0x7fffd9ab8700 (LWP 29750)]
[New Thread 0x7fffd92b7700 (LWP 29751)]
[New Thread 0x7fffd8ab6700 (LWP 29752)]
[New Thread 0x7fffb700 (LWP 29753)]
[New Thread 0x7fffbf7fe700 (LWP 29754)]
[New Thread 0x7fffbeffd700 (LWP 29755)]
[New Thread 0x7fffbe7fc700 (LWP 29756)]
[New Thread 0x7fffbdffb700 (LWP 29757)]
[New Thread 0x7fffbd7fa700 (LWP 29758)]
[New Thread 0x7fffbcff9700 (LWP 29759)]
[New Thread 0x7fff8bfff700 (LWP 29760)]
[New Thread 0x7fff8b7fe700 (LWP 29761)]
[New Thread 0x7fff8affd700 (LWP 29762)]
[New Thread 0x7fff8a7fc700 (LWP 29763)]
beast-0.15.0: ignoring note-on (783.990845Hz) for foreign midi channel: 1
beast-0.15.0: ignoring note-on (698.456482Hz) for foreign midi channel: 1
beast-0.15.0: ignoring note-on (523.251160Hz) for foreign midi channel: 1
beast-0.15.0: ignoring note-on (440.00Hz) for foreign midi channel: 1
beast-0.15.0: ignoring note-on (523.251160Hz) for foreign midi channel: 1
beast-0.15.0: ignoring note-on (493.883301Hz) for foreign midi channel: 1
beast-0.15.0: ignoring note-on (659.255127Hz) for foreign midi channel: 1
[Thread 0x7fffdaaba700 (LWP 29747) exited]
[New Thread 0x7fffdaaba700 (LWP 32028)]
[New Thread 0x7fff89ba5700 (LWP 32029)]
[Thread 0x7fffdaaba700 (LWP 32028) exited]
[Thread 0x7fff89ba5700 (LWP 32029) exited]
[New Thread 0x7fff89ba5700 (LWP 32030)]
beast-0.15.0: ignoring note-on (698.456482Hz) for foreign midi channel: 1

Thread 3 "BseSequencer" received signal SIGSEGV, Segmentation fault.
[Wechseln zu Thread 0x7fffebaf3700 (LWP 28767)]
0x77848626 in (anonymous namespace)::MidiChannel::no_poly_voice 
(this=0x7fffe505f8e0, noteon=true, event_name=0x77bf45e5 "note-on", 
freq=698.456482)
at bse/bsemidireceiver.cc:1110
1110  if (bse_module_is_scheduled (mchannel->voices[i]->vmodule))
(gdb) bt
#0  0x77848626 in (anonymous 
namespace)::MidiChannel::no_poly_voice(bool, char const*, float) 
(this=0x7fffe505f8e0, noteon=true, event_name=0x77bf45e5 "note-on", 
freq=698.456482) at bse/bsemidireceiver.cc:1110
#1  0x77848b4e in (anonymous 
namespace)::MidiChannel::start_note(guint64, gfloat, gfloat, BseTrans*) 
(this=0x7fffe505f8e0, tick_stamp=2132723, freq=698.456482, 
velocity=0.629921257, trans=0x7fffdc003908) at bse/bsemidireceiver.cc:1200
#2  0x7784c340 in midi_receiver_process_event_L(BseMidiReceiver*, 
guint64) (self=0x7fffe4a66a70, max_tick_stamp=2132723) at 
bse/bsemidireceiver.cc:2120
#3  0x7784942e in bse_midi_receiver_farm_process_events(unsigned long) 
(max_tick_stamp=2132723) at bse/bsemidireceiver.cc:1340
#4  0x77838692 in bse_midi_decoder_push_data(BseMidiDecoder*, unsigned 
int, unsigned char*, unsigned long) (self=0x7fffe4fe3da0, n_bytes=3, 
bytes=0x7fffebaf0930 

Re: [tim-janik/beast] Port Super author/license to C++ (#110)

[Stefan Westerfeld via beast]

I also don't know how to port sfi_pspec_time typed properties. And copyright 
looks like it can be removed (?), has a `// COMPAT-FIXME: remove around 0.7.0`

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/110#issuecomment-515794354___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] Port Super author/license to C++ (#110)

[Stefan Westerfeld via beast]

This is the first string property port that uses the `APPLY_IDL_PROPERTY` 
macro. Since there is no version of `constrain_idl_property` for strings, your 
code didn't compile when instantiated with strings. So I used C++17 `if 
constexpr` for checking for the type which compiles now. This means strings are 
not constrained (and all other types). If that wasn't your intention when 
writing the code, probably a String specialization of `constrain_idl_property` 
would be better.

I preserved the quark setting/getting (no idea why it is done this way in the 
first place). However I wonder if SuperImpl shouldn't simply have two string 
members, one for author and one for license.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/110

-- Commit Summary --

  * BSE: bseitem: allow APPLY_IDL_PROPERTY for Strings and other types
  * BSE: Super: port author/license properties to C++

-- File Changes --

M bse/bseapi.idl (2)
M bse/bseitem.hh (2)
M bse/bsesuper.cc (95)
M bse/bsesuper.hh (7)

-- Patch Links --

https://github.com/tim-janik/beast/pull/110.patch
https://github.com/tim-janik/beast/pull/110.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/110
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] Track primitive properties ported to C++ (#109)

[Stefan Westerfeld via beast]

I've ported all Track properties to C++ that do not contain object references. 
Two things are worth mentioning.

1. `Const MIDI_MAX_CHANNEL` - I declared this as constant, but maybe the 
definition must be moved elsewhere. It seems to be required in bsebasics.idl, 
too (there is a `// FIXME: MAX_MIDI_CHANNEL` in the `MidiChannelEvent` 
definition)
2. I didn't touch `"signal::property-notify::n-voices"` and similar signal code 
in bsttrackview.cc, I'm not sure what the C++ property equivalent would be
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/109

-- Commit Summary --

  * BSE: Track::muted: port property to C++
  * BEAST-GTK: bsttrackview: use muted C++ property
  * BSE: Track::midi_channel: port property to C++
  * BEAST-GTK: bsttrackview: use midi_channel C++ property
  * BSE: Track::n_voices: port property to C++
  * BEAST-GTK: bsttrackview: use n_voices C++ property

-- File Changes --

M beast-gtk/bsttrackview.cc (26)
M bse/bseapi.idl (16)
M bse/bsetrack.cc (107)
M bse/bsetrack.hh (6)

-- Patch Links --

https://github.com/tim-janik/beast/pull/109.patch
https://github.com/tim-janik/beast/pull/109.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/109
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

[tim-janik/beast] Fluid 2.0.5 update (#108)

[Stefan Westerfeld via beast]

Here are the two commits (cherry-picked) which update our code to fluidsynth 
2.0.5. This finally uses the new - non deprecated - `fluid_synth_process()`.
You can view, comment on, or merge this pull request online at:

  https://github.com/tim-janik/beast/pull/108

-- Commit Summary --

  * config-checks.mk: require the latest fluidsynth version, 2.0.5
  * BSE: SF2: use fluid_synth_process() instead of deprecated function

-- File Changes --

M bse/bsesoundfontosc.cc (26)
M config-checks.mk (2)

-- Patch Links --

https://github.com/tim-janik/beast/pull/108.patch
https://github.com/tim-janik/beast/pull/108.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/108
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

spectmorph-0.5.0

[Stefan Westerfeld via beast]

spectmorph-0.5.0 has been released.

Overview of Changes in spectmorph-0.5.0:

* Support user defined instruments
  - graphical instrument editor
  - new WavSource operator
* Make standard instrument set smaller (less download/disk usage)
* Graphical ADSR editor
* Added "SpectMorph User Manual" (online: html/pdf)
* Use different colors for active/used/unused operators
* LV2 now requires instance access feature
* Add file dialog wrapper shell scripts to work with some ardour bundles
* Integrate XML (pugixml) and ZIP (minizip) 3rd party code
* Minor fixes and cleanups

What is SpectMorph?
---
SpectMorph is a free software project which allows to analyze samples of
musical instruments, and to combine them (morphing). It can be used to
construct hybrid sounds, for instance a sound between a trumpet and a
flute; or smooth transitions, for instance a sound that starts as a
trumpet and then gradually changes to a flute.

SpectMorph ships with many ready-to-use instruments which can be
combined using morphing.

SpectMorph is implemented in C++ and licensed under the GNU LGPL version 3

Integrating SpectMorph into your Work
-
SpectMorph is currently available for Linux and Windows users. Here is a
quick overview of how you can make music using SpectMorph.

- VST Plugin, especially for proprietary solutions that don't support LV2.
  (Available on Linux and 64-bit Windows)
- LV2 Plugin, for any sequencer that supports it.
- JACK Client.

Note that at this point, we may still change the way sound synthesis
works, so newer versions of SpectMorph may sound (slightly) different
than the current version.

Links:
--
Website:  http://www.spectmorph.org
Download: http://www.spectmorph.org/downloads

There are many audio demos on the website, which demonstrate morphing
between instruments.
-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Eliminate global Soundfont Mutex (#84)

[Stefan Westerfeld via beast]

Closed #84.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/issues/84#event-2475700146___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Eliminate global Soundfont Mutex (#84)

[Stefan Westerfeld via beast]

The global soundfont lock has been eliminated with merging 
https://github.com/tim-janik/beast/pull/102 so I close this issue.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/issues/84#issuecomment-510459599___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Spectmorph plugin (rebase) (#30)

[Stefan Westerfeld via beast]

This plugin uses parts of the SpectMorph API that are no longer supported in 
the upcoming SpectMorph 0.5.0 and above.

In 0.4.x, the host can
 - manage polyphonic instantiation itself, which this BEAST plugin does, i.e. 
for a track with 16 voices, there are 16 `MorphPlanVoice` instances, each host 
voice corresponds to one internal SpectMorph voice - the host interprets 
note-on/note-off and renders voices
 - leave it to SpectMorph and just send note-on and note-off events using 
SpectMorph's `MidiSynth`

The instrument editor / WavSource operator introduced in SpectMorph 0.5.0 
requires that the voice management is done by SpectMorph, which is what 
SpectMorph smjack, VST and LV2 have always done. This means that using 
SpectMorph inside BEAST's modular synthesis engine is no longer possible. With 
0.4.x you could add a BEAST filter with BEAST ADSR after the SpectMorph plugin, 
and it would be done per voice. With 0.5.x this is no longer possible.

So I'd recommend that we don't merge this as-is, because it would allow 
creating sounds that would no longer be supported by newer SpectMorph (>= 
0.5.0). Instead, once we have some kind of Device API, the BEAST-SpectMorph 
plugin should use it. This would also repair the "Portamento Mono" mode 
SpectMorph has, which depends on having the midi notes available.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/30#issuecomment-510043491___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Bus properties ported to C++ - redone with APPLY_IDL_PROPERTY() macro (#105)

[Stefan Westerfeld via beast]

> Please fix review comments I left for you and remove:
> a) the commit introducing the block/unblock API,

Done with all code that depends on it.

> b) the float64 workaround.

Done.

> If that means you updated PR is broken, point out the bugs you're runing into 
> and I'll give you a hand with the fixes. In particualy, I'm not even sure you 
> can trigger buggy behaviour due to not blocking undo, if you find a way to 
> trigger that, that'd be really helpful.

I haven't ever seen any undo related problem while testing it.

> As for fixing the float parsing, I looked into that earlier and am quite 
> confident I can fix parse_paren_rest. I just needed an actual test case that 
> triggered breakage, which I didn't have at the time.

Right. `make check` is broken now due to audio tests, so before merge, you 
should look into fixing the parser.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/105#issuecomment-497718007___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Bus properties ported to C++ - redone with APPLY_IDL_PROPERTY() macro (#105)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> @@ -1335,4 +1337,16 @@ ItemImpl::apply_idl_property_need_undo (const 
> StringVector )
   return !Aida::aux_vector_check_options (kvlist, "", "hints", "skip-undo");
 }
 
+void
+ItemImpl::block_property_undo()
+{

Ok, I just tried to do a 1:1 port so I had to do something where the old code 
blocked undo. If you say you believe it is not necessary, thats even better, 
because the code looks cleaner now. I removed block/unblock now.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/105#discussion_r289398764___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Bus properties ported to C++ - redone with APPLY_IDL_PROPERTY() macro (#105)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> @@ -681,7 +683,7 @@ SongImpl::remove_bus (BusIface _iface)
   BseItem *child = bus.as();
   BseUndoStack *ustack = bse_item_undo_open (self, __func__);
   // reset ::master-output property undoable

Fixed.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/105#discussion_r289397537___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Bus properties ported to C++ - redone with APPLY_IDL_PROPERTY() macro (#105)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



>Bse::BusImpl *bus = child->as();
+  bus->block_property_undo();

Ok, I removed the block/unblock stuff now.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/105#discussion_r289397477___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Bus properties ported to C++ - redone with APPLY_IDL_PROPERTY() macro (#105)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



>if (BSE_IS_SONG (parent))
 {
   BseSong *song = BSE_SONG (parent);
   BseBus *master = bse_song_find_master (song);
-  return (self == master);
+  return self == master;

Thanks for the hint, I normally don't need this while coding, but I tried to 
fix everything here that could be done by history rewriting using git rebase -i 
now.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/105#discussion_r289397286___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Bus properties ported to C++ - redone with APPLY_IDL_PROPERTY() macro (#105)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> @@ -89,8 +89,24 @@ bus_build_param (BstBusEditor *self,
  const gchar  *editor,
  const gchar  *label)
 {
-  GParamSpec *pspec = bse_proxy_get_pspec (self->item, property);
-  self->params = sfi_ring_prepend (self->params, bst_param_new_proxy (pspec, 
self->item));
+  GxkParam *gxk_param = nullptr;
+
+  /* aida property? */
+  Bse::BusH bus = Bse::BusH::__cast__ (bse_server.from_proxy (self->item));
+  const Bse::StringSeq meta = bus.find_prop (property);

Fixed in a later commit.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/105#discussion_r289396411___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Bus properties ported to C++ - redone with APPLY_IDL_PROPERTY() macro (#105)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> +  if (BSE_IS_SONG (parent))
+{
+  BseSong *song = BSE_SONG (parent);
+  return song->solo_bus == self;
+}
+  return false;
+}
+
+void
+BusImpl::solo (bool is_solo)
+{
+  BseBus *self = as();
+
+  if (solo() != is_solo)
+{
+  auto prop = "solo";

Fixed.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/105#discussion_r289396448___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Bus properties ported to C++ - redone with APPLY_IDL_PROPERTY() macro (#105)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> @@ -89,8 +89,24 @@ bus_build_param (BstBusEditor *self,
  const gchar  *editor,
  const gchar  *label)
 {
-  GParamSpec *pspec = bse_proxy_get_pspec (self->item, property);
-  self->params = sfi_ring_prepend (self->params, bst_param_new_proxy (pspec, 
self->item));
+  GxkParam *gxk_param = nullptr;
+
+  /* aida property? */
+  Bse::BusH bus = Bse::BusH::__cast__ (bse_server.from_proxy (self->item));

I fixed this in a later commit.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/105#discussion_r289396350___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Bus properties ported to C++ - redone with APPLY_IDL_PROPERTY() macro (#105)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> @@ -1003,6 +993,25 @@ BusImpl::BusImpl (BseObject *bobj) :
 BusImpl::~BusImpl ()
 {}
 
+bool
+BusImpl::mute() const
+{
+  BseBus *self = const_cast (this)->as();
+
+  return self->muted;
+}
+
+void
+BusImpl::mute (bool val)
+{
+  BseBus *self = const_cast (this)->as();
+
+  if (APPLY_IDL_PROPERTY (self->muted, val))
+{

Ok, the lines caused by { } are not really necessary, so I removed then. I'd 
still like to keep a blank line between BseBus *self and the rest of the code. 
Obviously "readability" is not an objective criterium but depends on the coder 
reading the code. But for me, the extra blank line makes the code more 
readable. I often use blank lines to seperate code in groups that belong 
together. And we're no longer coding with 80x24 terminals, so we have space for 
many lines on the screen.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/105#discussion_r289396024___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] Bus properties ported to C++ - redone with APPLY_IDL_PROPERTY() macro (#105)

[Stefan Westerfeld via beast]

swesterfeld commented on this pull request.



> @@ -89,8 +89,24 @@ bus_build_param (BstBusEditor *self,
  const gchar  *editor,
  const gchar  *label)
 {
-  GParamSpec *pspec = bse_proxy_get_pspec (self->item, property);
-  self->params = sfi_ring_prepend (self->params, bst_param_new_proxy (pspec, 
self->item));
+  GxkParam *gxk_param = nullptr;

Right. This has been refactored in a later commit, so the issue is effectively 
resolved.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/105#discussion_r289395958___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Re: [tim-janik/beast] One fluid synth per track (#102)

[Stefan Westerfeld via beast]

> The reason the GUI blocks instrument changes is that the BSE core hasn't had 
> support for this yet. If soundfonts can implement changes during runtime, the 
> associated, we'll of course release that restriction and make it user 
> accessible. I guess that's better left for another PR, right?
 
I agree. As I understand it, updating beast-gtk is to be avoided, I suppose 
this should be done once ebeast supports assigning soundfont & preset with the 
new ui. The fluid code as it is supports changing the preset of an existing 
track during play. It doesn't support changing the SF2 filename of a track 
during play, but this could be implemented by swapping the fluid_synth_t 
instance in this case. Maybe that should be done after you have the new engine 
module api.

Anyway I think I've addressed the other issues now, will reassign this to you 
so you can merge it.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/102#issuecomment-494512399___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast