Beast End Of Life
PSA: Beast development has reached its end-of-life some while ago. At this point, Beast developments have been merged into Anklang [1] which took over many parts of the Beast synthesis engine and continues the UI developments that started out with Vue + Electron as ebeast. The Anklang synthesis engine already supports the CLAP [2] plugin format and other parts from Beast (e.g. Jack driver, Freeverb) are incrementally merged back as time permits. The GNOME project is also shutting down this mailing list in the next few days, so further questions or comments are best directed at the Anklang team via the #Anklang IRC channel [2] or the Anklang issue / discussion tracker. [1] https://github.com/tim-janik/anklang [2] https://web.libera.chat/#Anklang -- Anklang Free Software DAW https://anklang.testbit.eu/ ___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] portamento plugin icon (#141)
Closed #141 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/141#event-7092851443 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] portamento plugin icon (#141)
Beast development is continued in [Anklang](https://github.com/tim-janik/beast/pull/github.com/tim-janik/anklang/). Also, this looks like a screen sized painting, there is no way to turn this into an icon that would help with the UI. Here are a few resources to help with icon design: https://community.kde.org/Guidelines_and_HOWTOs/Icon_Workflow_Tips https://teams.pages.gitlab.gnome.org/Design/hig-www/guidelines/app-icons.html ``` General Guidelines Design icons with a small number of metaphors that are understandable independent of language and culture. Apply metaphors only once (e.g. don't use a brush twice for different actions). Simplify, but don't go overboard. Avoid using text in icon designs; it cannot be localized and tends to look bad at small sizes. ``` -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/141#issuecomment-1200053760 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] BEAST: automatically create and connect new bus for new tracks (#16)
Thank you for your efforts. Beast development is continued in [Anklang](https://github.com/tim-janik/beast/pull/github.com/tim-janik/anklang/). For the record, Undo recording is easier in Anklang. Anklang pushes C++ lambdas onto the undo stack where objects are pointer-referenced and kept alive via std::shared_ptr<>. Undo for objects (track, clip, etc) removal isn't implemented yet, but the plan is to allow repeated unparent/reparent states on objects, which will make Undo a lot easier and avoids dangling references automatically. The reparenting is something that would have been a lot harder to implement for Beast. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/pull/16#issuecomment-1200052460 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: fix undo problems that occur after removing a bus (#82)
Closed #82. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/pull/82#event-7092834234 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: fix undo problems that occur after removing a bus (#82)
Beast development is continued in [Anklang](https://github.com/tim-janik/beast/pull/github.com/tim-janik/anklang/). -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/pull/82#issuecomment-1200051275 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)
Closed #129. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/pull/129#event-7092831705 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)
Thank you for your efforts. While this had been merged into Beast, Beast development is continued in [Anklang](github.com/tim-janik/anklang/). Anklang has recently gotten Jack support, based on your PR submission. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/pull/129#issuecomment-1200050920 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] Properties that have Objects as value are currently not portable to C++ (#113)
Beast development is continued in [Anklang](github.com/tim-janik/anklang/) -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/pull/113#issuecomment-1200050707 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] Properties that have Objects as value are currently not portable to C++ (#113)
Closed #113. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/pull/113#event-7092830342 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] Rewrite Midi + Synth-Engine Integration (#103)
Beast development is continued in [Anklang](github.com/tim-janik/anklang/) which processes MIDI in the synthesis engine thread. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/103#issuecomment-1200049794 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] Rewrite Midi + Synth-Engine Integration (#103)
Closed #103 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/103#event-7092824886 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] Removing a bus doesn't undo properly (#79)
Closed #79 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/79#event-7092823194 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] Removing a bus doesn't undo properly (#79)
Beast development is continued in [Anklang](github.com/tim-janik/anklang/) -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/79#issuecomment-1200049527 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] Reproducable crash using MidiSynth midi channel setting (#111)
Beast development is continued in [Anklang](github.com/tim-janik/anklang/) -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/111#issuecomment-1200049402 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] Reproducable crash using MidiSynth midi channel setting (#111)
Closed #111 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/111#event-7092822558 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] Migrate IDL (#94)
Beast development is continued in [Anklang](github.com/tim-janik/anklang/) -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/94#issuecomment-1200049315 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] Migrate IDL (#94)
Closed #94 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/94#event-7092821939 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] Reproducable crash with mono voice count (#37)
Beast development is continued in [Anklang](github.com/tim-janik/anklang/) -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/37#issuecomment-1200049255 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] Reproducable crash with mono voice count (#37)
Closed #37 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/37#event-7092821516 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] Mono voices sometimes don't play notes (#26)
Beast development is continued in [Anklang](github.com/tim-janik/anklang/) -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/26#issuecomment-1200049185 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] Mono voices sometimes don't play notes (#26)
Closed #26 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/26#event-7092820976 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] Translated SNet module menu duplication (#20)
Beast development is continued in [Anklang](github.com/tim-janik/anklang/) -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/20#issuecomment-1200048936 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] Translated SNet module menu duplication (#20)
Closed #20 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/20#event-7092819445 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] Mixer assignment broken (#10)
Closed #10 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/10#event-7092817906 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] C++17 Migration (#93)
Closed #93 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/93#event-7092816779 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] Remove Gtk+ based GUI (#97)
Closed #97 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/97#event-7092816409 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] Python3 Build Tools (#96)
Beast development is continued in [Anklang](github.com/tim-janik/anklang/) which is py3 only. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/96#issuecomment-1200048179 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] Python3 Build Tools (#96)
Closed #96 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/96#event-7092815035 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] Track+Bus Merge (#104)
Closed #104 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/104#event-7092814588 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] Crashes in Resampler (#138)
Beast development is continued in [Anklang](github.com/tim-janik/anklang/), this should be fixed there. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/138#issuecomment-1200048007 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] No sound without -p alsa=pulse (#119)
Closed #119 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/119#event-7092812269 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] No sound without -p alsa=pulse (#119)
Beast development is continued in [Anklang](github.com/tim-janik/anklang/) which has Jack support. If you think snd_pcm_link errors should be ignored during auto detection, please make a case there. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/119#issuecomment-1200047819 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] asio error (#133)
Beast development is continued in [Anklang](github.com/tim-janik/anklang/) and boost::asio appears to compile fine there. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/133#issuecomment-1200046739 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] I have made a icon library for beast (#146)
Beast development is continued in Anklang. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/146#issuecomment-1200046316 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] I have made a icon library for beast (#146)
Closed #146 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/146#event-7092803350 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] add support for PipeWire (#147)
Closed #147 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/147#event-7092801995 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] add support for PipeWire (#147)
Beast development is continued in Anklang, which supports, ALSA, PulseAudio and Jack. That handles current user's needs. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/issues/147#issuecomment-1200046025 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)
Closed #41. -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/pull/41#event-7092793346 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)
Great, thanks a lot for this summary! -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/pull/41#issuecomment-1200044587 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)
@swesterfeld is this something that can be turned into a LiquidSFZ or Anklang bug? I don't want the work that went into this go to waste, but I wonder what the best way forward is with Anklang taking over from Beast... -- Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/pull/41#issuecomment-1199953264 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
Anklang 0.1.0 Released
Anklang version 0.1.0 is released. Anklang is a digital audio synthesis application for live creation and composition of music. It is released as Free Software (MPL-2.0) and runs under Linux. The real-time sound engine is implemented in C++, the UI runs in Electronjs, Firefox or Chrome. Assistance with development, porting or creative efforts is very welcome. With version 0.1.0, Anklang provides a MIDI sequencer, Undo/Redo capabilities for note editing, real-time synthesis, and support for CLAP plugins. The source code and binary packages are available here: https://github.com/tim-janik/anklang/releases/tag/v0.1.0 The project website with further resources is at: https://anklang.testbit.eu/ The release NEWS are appended. Anklang 0.1.0 System Requirements Linux - Ubuntu 20.04 is needed to run the Anklang AppImage Hardware Support Build and package a second sound engine binary with AVX & FMA optimizations. Documentation Extended documentation in many places. Improved copyright listing of all source files involved. Provide user documentation as anklang-manual.pdf. Provide developer documentation as anklang-internals.pdf. User Interface Improve UI responsiveness when handling async API calls. Support proper note selection sets in the piano roll. Introduced Undo/Redo stack for piano roll changes. Use batch processing to responsively handle thousands of notes. Support shortcut editing for piano roll functions. Added Cut/Copy/Paste to piano roll. Added play position indicator to piano roll. Tool selection in piano roils now works on hover. Notes moved in the piano roll now properly bounce against edges. Selection in the piano roll now supports SHIFT and CONTROL. Clips can now store notes with velocity=0. Migrated CSS processing to postcss. Fix file path handling for project load and save. Shortend nicknames are now auto-derived for external plugins. Support loading of command line files in Anklang. Add MIME support for starting Anklang for *.anklang files. Synthesis Support single clip looping (very rudimentary), to be extended later. Add Gtk+-2 dynlib to provide a wrapper window for plugin UIs. Add support for CLAP-1.0.2 plugin loading and processing, the following CLAP extensions are currently implemented: LOG, GUI, TIMER_SUPPORT, THREAD_CHECK, AUDIO_PORTS, PARAMS, STATE, POSIX_FD_SUPPORT, AUDIO_PORTS_CONFIG, AUDIO_PORTS, NOTE_PORTS. Internals Provide infrastructure for future piano roll scripting. Support lean UI component implementations with lit.js. Use ZCAM color model to design/saturate/etc colors of the UI. Updated various third party components. Use Electron-18.3.5 as basis for the UI. Use adaptive ZSTD compression for project storage. Use fast ZSTD compression for binary snapshots in Undo/Redo steps. Support sound engine blocks up to 2k. Adjust block sizes to reduce PulseAudio overhead. Keys matching in ASE_DEBUG is now case insensitive. Anklang can now be started with '--dev' to force open DevTools. Other License clarification, the project uses MPL-2.0. Improved reproducible dockerized builds. Fixed dependencies of the Debian packages. #3 -- Anklang Free Software DAW: https://anklang.testbit.eu/ ___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] new engine (#150)
Closed #150. -- 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/150#event-5266064935___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] new engine (#150)
Once the Firefox folks decide to provide proper Kiosk mode in Firefox (servo based), we can support that as alternative UI engine. -- 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/150#issuecomment-914341904___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
License Statement
As code contributed to open source projects is generally recommended to be made available under the terms of that project's existing license(s), here is my licensing 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. -- Yours sincerely, Tim Janik https://testbit.eu/timj Free software author. ___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
[tim-janik/beast] DavOrgan harmonics aren't working as expected (#148)
Migrated from: https://bugzilla.gnome.org/show_bug.cgi?id=353456 *Stefan Westerfeld:* Within a musical context, there is the fundamental frequency, and harmonics, where higher harmonics correspond to higher frequencies. There is a wikipedia entry with details: http://en.wikipedia.org/wiki/Harmonics Thus, I'd expect that the harmonics properties reflect this idea: higher harmonic -> higher frequency. However, by trying out how using 16th, 8th and so on sounds, it seems that higher harmonics correspond to lower frequencies in the DavOrgan module, i.e. that 16th corresponds to the lowest frequency, and 2nd corresponds to the highest frequency. That seems strange to me. The behaviour of CVS HEAD and 0.6.6 as packaged by debian/unstable is the same here, so its not a recently introduced problem. *Tim Janik:* more details on this bug are provided on the mailing list: http://mail.gnome.org/archives/beast/2006-December/msg00015.html *Hanno Behrens:* As I mentioned in the beast mailinglist, this is a misleading naming, not a real bug. If you build organs the pipes are named after their length. An eight feet (8') long pipe is the normal length and therefor the base frequency. A 16' pipe is an octave deeper, a 4' an octave higher than that and so on. 2' therefor two octaves, 1' three octaves. When you review my "How organs work" mailing on the beast mailing list you can find which length are corresponding to which frequency. The 1/3th for example correspondent to quintes, the 1/5th to terz means for the multiple of the 3rd harmonic or the 5th harmonic and so on for 7,9,11,13... So, what does this mean for the DavOrgan module? The naming as "harmonic" is completely wrong. Its the length of the pipes. Simply that is. And this naming is (for organ pipes) shure better than harmonics. Why? There are pipe length that do not directly corresponded to a harmonic but to a harmonic of maybe a 16' pipe. Like 5' 1/3: this is the quint of the 16' pipe. If you multiply 5 1/3 by 3 you get - 16! Voilà. Its the third harmonic of one octave deeper than the base-tone. -- 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/148___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Blepsynth improvements (#143)
Thanks, its merged now, except for triggering C-G, these still help with testing atm. -- 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#issuecomment-663843659___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Jack driver (#31)
Closed #31. -- 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/31#event-3546325113___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Jack driver (#31)
Since #128 was merged, this can be closed. -- 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/31#issuecomment-658467581___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] BSE: bse_cast - an API suggestion of how to handle bse object casts (#34)
Ultimately, the Bse* C-Objects are scheduled for removal now, so I guess this isn't needed anymore. -- 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/34#issuecomment-658464862___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] BSE: bse_cast - an API suggestion of how to handle bse object casts (#34)
Closed #34. -- 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/34#event-3546305969___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Resampler accuracy tests fail (#139)
Closed #139 via 55094ca55672bd6c80358dc8128c521adece1fd2. -- 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/139#event-3546298919___ 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)
Great! Thanks a lot for the detailed analysis. -- 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-658463809___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Feature Request: support portamento (#5)
> Yes, thats what I was looking for. Using f(x)=x^slope is not only always > monotonically increasing and adjustable, it is also trivial to invert > (x^(1.0/slope)). Indeed, hadn't thought of it in terms of inversion, but I needed that for implementing logscale knobs for the new Processor parameters (cannow be found in ebeast/b/pro-input.vue), It turns out slope is determined by specifying a logscale center like so: ``` // Determine exponent, so that: // begin + pow (0.0, exponent) * (end - begin) == begin ← exponent is irrelevant here // begin + pow (0.5, exponent) * (end - begin) == center // begin + pow (1.0, exponent) * (end - begin) == end← exponent is irrelevant here // I.e. desired: log_0.5 ((center - begin) / (end - begin)) ``` Example in gnuplot: ``` 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 ``` > I can think of only one reason to use x^3 rather than the generic x^slope: if > we had all properties automatable and some value ramp for portamento glide, > then we would possibly want to compute the mapping from input modulation > interval [0,1] to portamento glide at every sample (for this particular > module it doesn't matter, but there may be time parameters that can be > tweaked at runtime like compressor-attack-ms or adsr-attack-ms or delay-ms). > Modulation should in general use a non-linear mapping from control value to > dsp parameter, I think the obvious choice would be to use the same mapping > like for the ui slider. I have just added logscale mappings to the Attack/Decay Env in Blepsynth in milliseconds: min=0, max=8000, logcenter=1000 With the above formulas, that results in e=3: `0 + pow (x, 3) * 8`, i.e. `slope=3; f(x)=8*x^slope;` But for the cutoff frequency, a completely different center was needed, so the slope there is indeed different, more like 4.75 - 5. -- 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-657033291___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Ladder Filter (#122)
It'd be great to have this ported to the new AudioSignal::Processor API and also be able to enable key-tracking -- 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#issuecomment-656304241___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] BLEP based oscillator (rebase) (#29)
Stefan, what's the plan here. Do we close this PR, now that an initial Blepsynth variant is merged? -- 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-655708163___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] BlepSynth initial implementation (#142)
Great! Looks like a really cool device. I've taken your advice and moved the sources into devices/blepsynth/ and adjusted the commit messages and sources. Under devices/, no dedicated Makefile.mk is needed, the *.cc files are picked up automatically. I've also cleaned up the includes (e.g. we always use our internal assert_return()), implemented NOTE_ON, NOTE_OFF and ALL_NOTES_OFF. To address some open issues in the sources: > TODO: unison_voices property should be an integer property, range 1-16, > default 1" * What is missing here? You can just set min/max and step=1. Later we can add a hint that a number-input might be better than a knob here. > TODO: cutoff property should have logarithmic scaling * I need the exact mappings here, e.g. minimum, center, maximum, e.g. 32.7, 523.25, 8372.02? These are C values taken from: https://www.inspiredacoustics.com/en/MIDI_note_numbers_and_center_frequencies * Or a function with input range, i.e. the above is roughly: 32.7 * 2**x > TODO: we need non-linear translation between percent and time/level * Same here, does the discussion we previously had on panning help here? > TODO: replace this with true midi input * Done, can we get rid of the Note toggles now? > TODO: should be easier to get choice value * Yes, I agree, we should make a topic on choice -> audio value mapping. > 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. -- 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-655230320___ 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)
> Relax expected accuracy for 24-bit subsampling from 126 to 124.5 dB, to fix > testresampler for clang9. > > This should fix #139. 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? -- 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-585864349___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Resampler accuracy tests fail (#139)
> Since we enabled -ffast-math, resampler accuracy tests have been failing. > Just build todays Beats master and run the checks: Note, for the test to fail, the build mode must be MODE=production, debug mode in particular doesn't trigger it, probably because of the lack of compiler optimizations in 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/issues/139#issuecomment-585737761___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
[tim-janik/beast] Resample accuracy fails (#139)
Since we enabled -ffast-math, resampler accuracy tests have been failing. Just build todays Beats master and run the checks: ``` out/tests/suite1 testresampler_check_precision_sub24 RUN… testresampler_check_precision_sub24 suite1: tests/testresampler.cc:810: testresampler_check_precision_sub24: assertion failed: run_accuracy (RES_SUBSAMPLE, false, 24, 90, 9000, 983, 126) ``` Maybe the error margins need to be extended, now that math precision can potentially be reduced, or maybe some float instructions really need adaptions. In particular `-fassociative-math` and `-freciprocal-math` may be the culprits here. See also: https://mail.gnome.org/archives/beast/2020-January/msg9.html -- 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/139___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] TESTS: testresampler: provide more information if accuracy test fails (#136)
Merged #136 into master. -- 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#event-3032877878___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] TESTS: make time consuming resampler tests run as slow tests (#137)
Closed #137 via 62998adac8d910a58105dba448b3f5535d087ff6. -- 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#event-3032877880___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
[tim-janik/beast] Crashes in Resampler (#138)
Compiling beast as follows crashes the resampler.
```
# disable ASAN spam to stderr about leaks
export ASAN_OPTIONS=detect_leaks=0
# build with address sanitizer
make default MODE=asan
make clean
make -j11
make check
```
Note that there's a mismatch in order indexing and allocation in
bseresampler.cc in several places:
```
# 418
fir_compute_sse_taps (const vector& taps)
{
const int order = taps.size();
vector sse_taps ((order + 6) / 4 * 16);
# 470
AlignedArray random_mem (order + 4);
for (uint i = 0; i < order + 4; i++)
random_mem[i] = 1.0 - rand() / (0.5 * RAND_MAX);
# 362
fir_process_4samples_sse (const float *input,
// ...
for (uint i = 1; i < (order + 6) / 4; i++)
{
out0_v.v=_mm_add_ps(out0_v.v, _mm_mul_ps(input_v[i].v,
sse_taps_v[i*4+0].v));
```
In the above snippet, `input_v == random_mem`. It is allocated as order+4 and
indexed as order+6.
--
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/138___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] TESTS: testresampler: provide more information if accuracy test fails (#136)
> Is this an acceptabe solution for making failed resampler tests report > details of why the test failed? Not quite, this patch doesn't affect the failing test: ``` #6 0x5e0d09 in testresampler_check_filter_impl() tests/testresampler.cc:799 ``` -- 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#issuecomment-585464725___ 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)
I now have a proper fast_log2() approximation. I used Sollya for this, and figured you only get a good approximation for log2(x+1), see here: https://en.wikipedia.org/wiki/Logarithm#Power_series That allows the constant of the approximation polynomial to be 0.0, which guarantees correct results for 2^int inputs. Tests and benchmark are now in master (results from a production build): BENCHfast_log2 # timing: fastest=0.000185s calls=487621127.8/s diff=0.0302175265787241 (@0.15) BENCHlog2f # timing: fastest=0.000342s calls=263339591.6/s diff=0.0095218742401926 (@0.10) -- 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-575898765___ 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)
Closed #124. -- 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#event-2960224192___ 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)
I just pushed a new version of the 2^x approximation as fast_exp2() to master and removed the old approximations. Commit 7d919e98bb116f98a6b05e56f8a05edb6825692e still has the old functions, and a comparative benchmark. The approximation is based on the 5th order polynomial with minimal relative error, approximating 2^x within [-0.5...+0.5], generated with [Sollya](http://sollya.gforge.inria.fr/). The result is almost as accurate as the old bse_approx6_exp2(), although fast_exp() uses only float arithmetic. It is also significantly faster than the old functions and the optimized exp2f() variant recently added to glibc and musl ([ARM-software/exp2f](https://github.com/ARM-software/optimized-routines/blob/master/math/exp2f.c)). git checkout 7d919e98bb116f98a6b05e56f8a05edb6825692e && make BSE_TEST=slow out/tests/suite1 fast_math_test fast_math_bench RUN… fast_math_test PASS fast_math_test RUN… fast_math_bench BENCHfast_exp2 # timing: fastest=0.000392s calls=458605760.0/s diff=0.0033028512169686 (@0.734155) BENCHarm_exp2f # timing: fastest=0.000532s calls=338185006.7/s diff=0.0005979062378536 (@0.958382) BENCHexp2f # timing: fastest=0.000650s calls=276832337.1/s diff=0.0005979062378536 (@0.958382) BENCHbse_approx5_exp2 # timing: fastest=0.000768s calls=234464124.9/s diff=0.0458521965707170 (@0.50) BENCHbse_approx6_exp2 # timing: fastest=0.000847s calls=212474853.5/s diff=0.0022838359092781 (@0.50) BENCHbse_approx7_exp2 # timing: fastest=0.000854s calls=210667974.8/s diff=0.994037496760 (@0.50) PASS fast_math_bench -- 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-575412715___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] TESTS: fix testresamplerq checks, make all failed assertions fatal (#134)
Closed by b85e36ed31352f9e74e3e1e272ad9c9243a7646b -- 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#issuecomment-573754309___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] TESTS: fix testresamplerq checks, make all failed assertions fatal (#134)
Closed #134. -- 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#event-2943906844___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] A few bsefcompare cleanups for cppcheck/scan-build issues (#135)
Closed #135. -- 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#event-2943907797___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] A few bsefcompare cleanups for cppcheck/scan-build issues (#135)
Closed by b85e36ed31352f9e74e3e1e272ad9c9243a7646b -- 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#issuecomment-573754416___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] TESTS: testresampler: add header file for test_resampler prototype (#126)
Closed #126 via b85e36ed31352f9e74e3e1e272ad9c9243a7646b. -- 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#event-2943484460___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Resampler cleanups (#125)
Closed #125. -- 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#event-2941248507___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Force alsa default device (#123)
Ebeast has PCM / MIDI device selection 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/123#issuecomment-573305914___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Force alsa default device (#123)
Closed #123. -- 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#event-2940547367___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Build fails on openSUSE Tumbleweed (#131)
Closed #131 via 3a43113880a5074ba20c9bdba4ae2ca330f89dfd. -- 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/131#event-2907459660___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Many build issues on FreeBSD (#132)
@yurivict wrote: > This subjects users to the danger of some of these accounts to go rogue and > deliver malware to them, since NodeJS technology doesn't have any safeguards > against this Related: [Two malicious Python libraries caught stealing SSH and GPG keys](https://news.ycombinator.com/item?id=21701488) There is no point in picking on npm (nodejs) specifically when it comes to malicious code being introduced via dependencies. Whatever language / runtime environment you use, always check your dependencies closely and pay close attention to name spoofing / typosquatting. > there's little chance that major packaging systems would adopt them. You can > see that the Atom editor for example isn't packaged by Debian FYI, here is the Debian bug for packaging Electron: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842420 And here is the Wiki page tracking the progress: https://wiki.debian.org/Javascript/Nodejs/Tasks/electron -- 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/132#issuecomment-561831549___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Many build issues on FreeBSD (#132)
> Electron apps package NodeJS code. Electron contains the google-chrome rendering engine libchromiumcontent, the google-chrome javascript engine V8 (sandboxed) and nodejs (a V8 based JS language environment, not sandboxed) in a single binary. That is similar to e.g. Firefox and and any language interpreter like Python or the JVM languages. > npm downloads NodeJS code directly from GitHub, typically from hundreds of > individual GitHub accounts. npm is a package manager and package repository for web applications and nodejs applications. packages are downloaded from npmjs.org. web applications are sandboxed like a website displayed in a browser. only nodejs applications and npm packages for nodejs could go rouge the way CPAN packages, PIP modules, JVM code, C, Go, Ruby, C++, Rust or shell code could after being downloaded. There is nothing special about npm here, other than it being used more widely, so its potentially a more attractive target. It has had dependency fallouts in the past, which is why procedures have been adapted now to prevent this in the future and make package name spoofing harder. Most Python, C, C++, etc code is hosted on Github these days btw, but whether Github is used for hosting or not is really not related. >This subjects users to the danger of some of these accounts to go rogue and >deliver malware to them, since NodeJS technology doesn't have any safeguards >against this and such unsafe behavior is done rather by its design, there's >little chance that major packaging systems would adopt them. I don't follow that argument, Electron has sandbox functionality, C, C++, Ruby, Python, Haskell, etc code that is pulled from Github and packaged doesn't. > Perhaps Electron can be used w/out NodeJS, but it brands itself as > ElectronJS, and your project too has the npm part in it. That is just not related. Most websites use npm packages and are used by billions of people, every day. Claiming that npm is bad or insecure or unusable or anything alike is just not credible. Regarding Beast, the package installation uses just one npm package, vue-2.6, and that comes with 0 dependencies. We used to also need jquery but could get rid of it. And I have probably studied more of the Vue code than I have studied the various C/C++ dependencies we pull in (those are pulled from Github btw). -- 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/132#issuecomment-561448200___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Many build issues on FreeBSD (#132)
> > FETCH for external packages is required > > All major packaging systems disallow fetch during build for security reasons, > rpm/debian/bsd As I wrote under (1) above, you could prefetch the downloaded 3rd party sources, and combined with the beast sources + Electron could build Beast offline. > > Beast now has a hard dependency on Electronjs > > NodeJS is hard-banned by all major packaging systems because NodeJS leads to > insecure packages and they just don't package such software. First, NodeJS doesn't lead to insecure software per se. Blindly installing npm deps can have that effect, yes, but that's not what the Beast build does. (And realistically, the same can happen with other language environments also.) Second, Beast doesn't even need the NodeJS portion of Electron, just a modern web engine to display the UI, which is why I wrote that Firefox could take on this part in the future also. Third, this is not the place to start a generic argument against use of Electron. If you care, https://electronjs.org/apps lists hundreds of apps that are based on Electron. It may take distributors some time - or years - to figure how and why they want to package Electron apps, but it will happen eventually due to user demand. > You made several design decisions that prevent most users from ever seeing > your software because you are asking them to compile it by hand instead of > installing it via a package. Compilation by hand is too hard for most users. You're right that compilation is too hard for users. We don't advocate that users should compile Beast to get it working. Instead, we provide a pre-built AppImage, that works on Ubuntu and Fedora systems. Distributors/packagers are welcomed to build Beast for platforms beyond that, and that process is actually quite easy, as GNU-Make will tell you what dependencies are missing and you could even inspect the CI Docker images to understand how the build works. Regarding the basic design choices that you talk about, we originally based Beast on Gtk+ and I invested heavily into that toolkit. As a result, ten years ago we had Debs, Rpms and earlier even BSD packages. The foundation wasn't good enough to keep up with feature requests and UI development demands though. Changing that has allowed to move Beast into new and more interesting directions, and that at a previously unimaginable pace. For now, the focus is on reaching feature completeness for a 1.0 version, and once that's achieved we can possibly dial back on one or two aspects to ease packaging and integration. For FreeBSD specifically, a proper desktop application webengine is required first - the need of which is also recognized by other FreeBSD users as demonstrated in https://github.com/electron/electron/issues/3797 -- 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/132#issuecomment-560019244___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Many build issues on FreeBSD (#132)
I think this is the Electronjs upstream bug that would have to be fixed first; https://github.com/electron/electron/issues/3797 -- 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/132#issuecomment-559958453___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Many build issues on FreeBSD (#132)
Closed #132. -- 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/132#event-2842671013___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Many build issues on FreeBSD (#132)
Hi @yurivict. I'm afraid FreeBSD builds are not possible atm. 1) FETCH for external packages is required, because we cannot have every dependency replicated in our repository. A cache in $HOME is supported though, so only the first build attempt really needs downloads. 2) Beast now has a hard dependency on Electronjs, and AFAICS that is not (yet) available for FreeBSD. So that needs to be fixed first. Alternatively, maybe some future version of Firefox will again support a standalone browser engine that can be used as desktop app, but without a standalone *modern* browser engine, Beast cannot be brought to live. 3) realpath and find and other tools used in the Makefiles use GNU specific options atm, porting to a pure POSIX command/option set is only useful once (2) is solved (and involves significant work in some cases). -- 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/132#issuecomment-559958222___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Build fails on openSUSE Tumbleweed (#131)
Please provide the glib and compiler versions you used for the build, i.e.: pkg-config --modversion glib-2.0 cc --version c++ --version -- 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/131#issuecomment-558174981___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] make check fails on Arch Linux (#130)
Hm, I *thought* our tests didn't try to load LADSPA plugins, but maybe that's not disabled...? About the fluidsynth error, @swesterfeld do you have an idea? -- 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/130#issuecomment-535691214___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Jack driver new api (#128)
Merged #128 via 7fb799ecca58d45b79e5630603da2ed49c5a2f09. -- 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#event-2653055404___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Jack driver new api (#128)
Merged #128 into master. -- 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#event-2653055398___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Jack driver new api (#128)
tim-janik requested changes on this pull request.
Great work Stefan, thanks for the updates.
I've pointed out a few places that still need work.
> +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
Use BSE_USED or BSE_UNUSED to silence the compiler here.
> +}
+
+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?
+}
No, if there's no jack, there are no devices to list. Simple. Stay silent.
> +}
+
+ for (std::map::iterator di = devices.begin(); di
!= devices.end(); di++)
+{
+ const std::string _name = di->first;
+ DeviceDetails = di->second;
+
+ /* 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);
Two Driver::Entry structures must never have the same priority. That's why we
have predefined priority constants for drivers, cards, devices, subdevices.
Also, we need the other Entry fields to be filled to allow GUI selection. For
now, it doesn't matter too much how to match name/blurb/status fields to extra
info, each is just another line in my current UI prototype, but we need
*something* to display devices to the user that make them humanly identifyable.
> + /* 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 */
+
I know this is disabled, atm, but please still make this /tmp/bse-dropout (or
similar) so we're not stamping over namespaces if this is activated on purpose
or by accident.
> + *
+ * Implementation: the synchronization between the two threads is only
+ * 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
This is C++17, always and unconditionally initialize all struct members that
don't have a ctor. If in doubt, just add =0, =false, =EnumType(0).
> + * 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_;
n_channels_ = 0;
> + 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
Re: [tim-janik/beast] BSE: driver-alsa.cc: fix crash in retrigger code (#127)
Closed #127 via 644460eb0ec5aea103eec2d85b919624fdb2cedf. -- 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#event-2650279047___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] BSE: driver-alsa.cc: fix crash in retrigger code (#127)
tim-janik requested changes on this pull request.
> @@ -427,7 +427,8 @@ class AlsaPcmDriver : public PcmDriver {
if (write_handle_)
{
int n, buffer_length = n_periods_ * period_size_; // buffer size
chosen by ALSA based on latency request
-const float *zeros = bse_engine_const_zeros (buffer_length / 2); //
sizeof (int16) / sizeof (float)
+const size_t frame_size = n_channels_ * sizeof (period_buffer_[0]);
+const uint8 zeros[buffer_length * frame_size] = { 0, };
Clang doesn't support intiializing variable length arrays from non-const.
Generally, period_size_ should never be bigger than the engineblock size,
actually the two should be same. It's probably most simple to call
snd_pcm_writei for n_periods_ times.
--
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#pullrequestreview-289763166___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Jack driver (#31)
An update on how this can be merged. This PR needs: 1) Updates so it uses the new Bse::Driver API and utilizes C++ classes instead of C structures. 2) We need to figure *how* to integrate Jack support into the AppImage. The AppImage build tools gather all system libraries needed by an applicaiton and pack those into the AppImage, so it can be run self-contained. But some libraries are blacklisted and the jack client library is one of those. The reason is that the Jack/libjack ABIs are tightly coupled, so that packing any libjack wouldn't neccessarily work on a system that runs a possibly completely different jackd version. However, there *are* AppImages out there with Jack support, IIRC they check and compile different libjack versions or something similar. I don't know the exact details, so solving this involves joining #AppImage on freenode, and asking TheAssassin / Probono which AppImages ship jack support so we can investigate those. -- 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/31#issuecomment-532593425___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Resampler cleanups (#125)
Your branch is merged, but the --resampler options needs fixing. -- 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-531899263___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Resampler cleanups (#125)
tim-janik 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 **);
NEVER inline prototypes, ALWAYS use a header file!
Without any exception.
I've once spent days debugging misbehaviour due to mismatching prototype, never
again!
--
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#pullrequestreview-288815945___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Force alsa default device (#123)
> Ok, first of all, I no longer think that changing the auto-detect order for > devices can solve our problem. I think we can get very close to 0-config for most users by doing this: 1) Pick Jack driver if and only if Jackd is running. 2) Pick Pulseaudio if it is available, note that this does not support snd_pcm_link and needs some drift compensation. 3) Pick the first ALSA HW device, that should support snd_pcm_link. 4) Otherwise leave it to the user via the preferences dialog. The only thing I'm not perfectly sure about is if a linked HW device (3) is better than Pulseaudio with drift compensation (2). From a quality standpoint, (3) would be clearly better. But imagine a user has Pulseaudio hooked up to his *second* ALSA device, e.g. USB headphones. If Beast prefers the first ALSA device over Pulseaudio, it can link Duplex channels, but may blast onto laptop speakers unintentionally or maybe utterly silent if hw:0,0 is a desktops onboard sound with an unconnected stereo jack. > 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've almost thrown away the entire preferences code in beast-gtk yesterday, because it depends on the Visitor code which doesn't compile due to a g++-8 bug. I did find a workaround in the end though. But don't count on that code to stay around much longer. > 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. Ebeast has had a preferences dialog since mid-May. We just need to add PCM device selection to 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-531332826___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Force alsa default device (#123)
A bit of evaluation on Ubuntu 18.04: - Bitwig defaults to opening JACK and issues a warning if that fails. It provides JACK, ALSA and PulseAudio drivers. For the ALSA driver, the user has to select one of the available ALSA hardware drivers (hw:*). - Reaper defaults to opening JACK and issues a warning if that fails. It does allow the user to manually select ALSA, a dummy driver or PulseAudio. Oddly enough, with ALSA it only recognizes the first hardware device. Reaper allows the project to render with a different sample rate than used by the audio device. - Renoise tries to open ALSA's *first* hw device (hw:0,0), its ALSA driver allows manual selection of all ALSA hardware devices (hw:*). If ALSA hw:0 doesn't work, it tries to fallback to its second driver JACK, if that doesn't work it gives up. - Firefox and Google-chrome simply use Pulseaudio out of the box and support Duplex operation. Via Pulseaudio, it's possible to change between Headphone and Laptop mic/speakers while a call is ongoing. Since they can also mix-in remote audio, they must have some kind of drift-compensation. Insisting on using a JACK driver when Jackd is not running or not even installed on a system is simply user-unfriendly. Renoise knows better and can play out of the box via ALSA, but if that doesn't work, it's worse of than any of the other programs, because it fails to recognize/use PulseAudio. The browsers are a magnitude more user friendly than any of the DAWs, they support PulseAudio out of the box, try to minimize latency for interactive calls, work in *Duplex mode out of the box* and compensate drift automatically. For Beast, we should simply work as well and as user-friendly as the browsers by picking PuleAudio by default, trying JACK only if Jackd is running and falling back to the first ALSA hw device if it is not busy. That way, power users can manually assign JACK as the default driver and for everyone else, things will work out of the box. But we need some kind of drift compensation when we use PulseAudio in 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/pull/123#issuecomment-530171565___ 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)
As mentioned on IRC, enabling optimizations with MODE=release and picking
clang++ (6.0 here) vs g++ (7.4 here) makes major differences when benchmarking
exp2f and log2f from glibc against our approximations. On a modern AMD64
processor, glibc is often faster. Internally it also uses polynomials around
order 4, but picks its coefficients from a table depending on the input
argument. With that it achieves errors < 1 ULP and is often speedier because
it can also use hand crafted SSE2 implementations.
I haven't had a chance to benchmark the approximations on musl, but so far,
based on your submission, I'm inclined to integrate the following:
1) Rename bse_approx6_exp2 to fast_exp2() and get rid of the other
approximation variants.
2) Add fast_log2() based on your 6th order version, but with error correction
for integer logarithms.
3) When building for AMD64, use exp2f to implement fast_exp2 and use log2f to
implement fast_log2.
Here's the error correction I'm talking about, note that exchanging "long
double" for "float" makes the code significantly slower, because it forces the
compiler to add code to reduce precision. On my machine, this version is
roughly as fast as log2f when compiling with optimizations, with both compilers:
static inline long double G_GNUC_CONST
fast_log2f (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;
long double u, x = float_u.f;
// lolremez --long-double -d 6 -r 1:2
"log(x)/log(2)+1-0.0184568668708"
u = -2.5691088815846393966e-2l;
u = u * x + 2.7514877034856806734e-1l;
u = u * x + -1.2669182593669424748l;
u = u * x + 3.2865287704176774059l;
u = u * x + -5.3419892025067624343l;
u = u * x + 6.1129631283200211528l;
x = u * x + -2.040042118396715321l;
return x + log_2;
}
Error samples, compared to LOG2L(3):
+0.0, -0.0231613294631
+0.5, +0.0
+1.0, +0.0
+1.1, -0.0181973000285
+1.5, -0.0130387210186
+1.8, -0.0312228549678
+2.0, +0.0
+2.2, -0.0181973000285
+2.5, -0.0140048214306
+3.0, -0.0130387210186
+4.0, +0.0
+5.0, -0.0140048214306
+6.0, -0.0130387210186
+7.0, -0.0312228549678
+8.0, +0.0
+9.0, -0.0084878575295
+10.0, -0.0140048214306
+11.0, -0.0368176020430
+16.0, +0.0
+32.0, +0.0
+40.0, -0.0140048214306
+48.0, -0.0130387210186
+54.0, -0.0149844406951
+64.0, +0.0
+127.0, -0.0162654178981
+128.0, +0.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/124#issuecomment-530135495___
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)
> Relative `exp2(x)` approximation errors in interval [-1:1]: That's a miniscule range to approximate, given the valid range of this function. Here are the errors of bse_approx3_exp2() at mostly integer steps with some omissions for brevity: -2.0, +0.0 -1.5, -0.00016133294256113 -1.0, +0.0 -0.5, -0.00032266588512226 +0.0, +0.0 +0.5, -0.00112351661969536 +1.0, +0.0 +1.5, -0.00224703323939071 +2.0, +0.0 +2.5, -0.00449406647878142 +7.0, +0.0 +11.0, +0.0 +16.0, +0.0 +32.0, +0.0 +40.0, +0.0 +48.0, +0.0 +54.0, +0.0 +64.0, +0.0 +127.0, +0.0 Now the same for fast_exp2<2>(): -2.0, +0.00011078548906696 -1.5, -0.00060979588254370 -1.0, +0.00022157097813391 -0.5, -0.00121959176508741 +0.0, +0.00044314195626782 +0.5, +0.00243918353017435 +1.0, +0.00088628391253565 +1.5, +0.00487836706034869 +2.0, +0.00177256782507129 +2.5, +0.00975673412069738 +7.0, +0.05672217040228134 +11.0, +0.90755472643650137 +16.0, +29.04175124596804380 +32.0, +1903280.20965576171875000 +40.0, +487239733.671875 +48.0, +124733371820 +54.0, +7982935796480 +64.0, +8174526255595520 +127.0, +75396696880394894980022595129180160 I.e. a pure Remez approximation works allmost as well as approxX_exp2 while using one less addmul, but only within -1:+1. I've discarded that approach when I wrote approxX_exp2, because outside of that range the error becomes gigantic. Above, I'm comparing approx3_exp2 with fast_exp2<2>, to show that with just one extra addmul, those giant errors can be avoided (which even fast_exp2<9> cannot accomplish) if the integer part and the fractional part are approximated separately. Considering that fast_exp2<>() are not even minimizing the error at exactly -1, +1, or at 0 at the very least, I'd at most add them as rough approximations to be used only when the input range is known to be -1..+1 (which is not the case for general audio signals in BSE). For that it might be named fast_narrow_exp2<>() or similar, but I think fast_exp2<>() is better used if we rename the current bse_approxX_exp2 functions. -- 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-530013074___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] BSE: add Resampler2 function to reset state (#121)
Closed #121 via 6c82539e6282b239fb25606d6e89d055e1b0c531. -- 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#event-2616469398___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Force alsa default device (#123)
This patch causes a regression on my system (Ubuntu 18.04 with pulseaudio) when opening media/Demos/stereo-through.bse. Without the patch, I can play this: BSE_DEBUG=snd pasuspender -- out/beast-gtk/beast-0.15.0 out/media/Demos/stereo-through.bse snd: bse_device_open: BsePcmDeviceALSA: default: Bse.Error.DEVICES_MISMATCH snd: bse_device_open: BsePcmDeviceALSA: null: Bse.Error.DEVICE_BUFFER snd: bse_device_open: BsePcmDeviceALSA: pulse: Bse.Error.DEVICES_MISMATCH snd: bse_device_open: BsePcmDeviceALSA: sysdefault:CARD=PCH: Bse.Error.DEVICES_MISMATCH snd: bse_device_open: BsePcmDeviceALSA: front:CARD=PCH,DEV=0: Bse.Error.NONE FYI, without pasuspend, opening 'front' gives Bse.Error.FILE_BUSY. So fixing 'default' as the only ALSA device to open doesn't work for opening in Duplex mode with pasuspend. Note that even without pulseaudio ([killing pulseaudio](https://askubuntu.com/questions/8425/how-to-temporarily-disable-pulseaudio/394872#394872)) running, I'm getting: >default:CARD=PCH - HDA Intel PCH, ALC298 Analog Default Audio Device >front:CARD=PCH,DEV=0 - HDA Intel PCH, ALC298 Analog Front speakers snd: bse_device_open: BsePcmDeviceALSA: default:CARD=PCH: Bse.Error.DEVICES_MISMATCH snd: bse_device_open: BsePcmDeviceALSA: front:CARD=PCH,DEV=0: Bse.Error.NONE So I'm not sure *what* ALSA picks as 'default' (without pulse), but it doesn't have matching mixfreq/fragment sizes which are needed for duplex mode. (BSE_DEBUG=snd is supported by recent master) -- 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-529153791___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] BSE: randomhash.hh: fix compilation on g++ 7.4.0 (#120)
Closed #120 via bdbbed4be3d1e1694ed0ab837693b9bbb8b95bb3. -- 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#event-2601456404___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] BSE: randomhash.hh: fix compilation on g++ 7.4.0 (#120)
fnv1a_consthash64() is named consthash because it proivdes a compile-time hash function, removing the constexpr means it cannot be used at compile time. It's a pitty that g++ doesn't handle this as well as clang, I'm removing the entire function for 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/120#issuecomment-527185964___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
