zebproj

> it seems like the main advantage is the environment that allows for more fluid iteration combined with functions for audio.

That's exactly right. Having a terse and precise notation for expressing a patch was originally why it was created. There are indeed lower level libraries in other languages powering this (Soundpipe), but I found working in C to be too slow for creative working. Sporth eliminated some of those keystrokes and enabled me to compose music I wouldn't have been able to do otherwise [0].

0: http://paulbatchelor.github.io/sporthlings/

I agree it would be a cool feature. Unfortunately, you'd have to basically rewrite everything in order to do it.

I actually kind of did that. Soundpipe[0], Patchwerk[1], and Runt[2] used together builds something that syntactically resembles Sporth, sounds virtually identical, and is usually way faster. In Runt, you can add new words and build abstractions that way. In practice, I tend to avoid doing this and will tend to generate Runt code using higher level languages like Scheme.

0: http://paulbatchelor.github.io/proj/soundpipe.html

1: http://paulbatchelor.github.io/proj/patchwerk/

2: http://paulbatchelor.github.io/proj/runt/

+1 on this.

the author also wrote an interactive tutorial here:

https://audiomasher.org/learn

this is based on the sporth cookbook, found here:

http://paulbatchelor.github.io/proj/cook/

Thank you for sharing. It's always fun to see the ways BF can be used to make music.

I really like the way the editor visually shows where you are. It would be really neat to get it controlling some synths in an Ableton live session or something. You'll get the notation system AND the great sounds that way.

At one point, I wrote a little BF sequencer for Sporth [0]. The nice thing about it was it just output a signal which could be mapped to literally any sound parameter at audio-rate. If the project still builds [1], there's a single demo that I made of it.

0: http://paulbatchelor.github.io/proj/spigot/

1: https://github.com/paulbatchelor/spigot

Could you elaborate on what you mean by that?

I am a casual user of Fossil. I tried it out for some of my smaller projects. I can't say I am at the point where I "get" it, but I'd definitely recommend at least trying it out, as it provides a contrasting perspective to source control (from git).

The integrated Wiki and ticketing system can be very helpful. The built-in web interface is definitely convenient. Also, the codebase is written in very clean C code (it's written by the SQLite devs, so I expect no less from them). It is very easy to compile from source. Also, the documentation they have is quite nice.

I definitely struggle with parts of Fossil. Fossil does not make it easy to revise commits (this is an intentional design). I one time made a commit on a badly time-skewed machine and it took me all day to look up how to correct that (but I found it in their documentation). I'm also still getting the hang of how branching works in Fossil. It is very hard to have a massive amount of contributors to code. Again, this is another intentional design choice.

It's certainly not a VCS for all projects. But for certain kinds of projects, it really works well.

I've been using org and org-mode for literate programming for the past few months. org-mode provides a really nice interactive environment suitable for literate programming, but tangling code is hilariously slow, to the point where several people [0] (including myself [1]), have written org tanglers. It'd be interesting to see benchmarks against the original org-mode implementation.

[0] https://github.com/orgtangle

[1] https://github.com/OrgTangle/Worgle

> I spent this weekend writing a Forth designed for music synthesis

I'd be very curious to learn more about this project. I've been building these myself [0] for a few years now.

[0] https://paulbatchelor.github.io/proj/sporth.html

I should, but I haven't gotten around to updating the page yet. I've been busy with other projects.

Creator of Sporth here. AudioMasher is a really cool project! Projects like this make me really glad I open sourced Sporth. It's really cool to see what sorts of things people will use it for. In addition to learning the API and porting it to the web (with no assistance from me), Pierre has also composed some very beautiful patches in Sporth using his AudioMasher tool. It is always easier to leave things as a "technical demo", so I appreciate the extra effort.

You kind learn more about Sporth here: https://pbat.ch/proj/sporth.html and the code can be downloaded here: https://www.github.com/paulbatchelor/sporth.git

> A theoretical "control-rate" "mtof" object would take its input value and compute a frequency value once every block when DSP is turned on.

In Sporth, the "mtof" unit-generator does a MIDI to frequency conversion for every audio sample, thus making it audio rate.

Perhaps it is better to think of control-rate signals as input signals rather than output signals. The "osc~" object, for instance, will update the frequency at every audio block. This would be the control rate. In Sporth, oscillator frequency values are updated every sample inside the audio block.

> But that's not what "mtof" does. Instead, it computes the frequency for an inputted MIDI value at the time it receives that value. That time could be once every block, once a minute, a single time when I load the program, at random intervals on Tuesday, or even never.

The important distinction here is that the resolution can't be smaller than the audio-block size, which in turn defines the control-rate.

In PD, the normal thin cables carry control-rate signals. The thicker cables are the audio-rate cables. Objects like "osc~" and "+~" produce audio-rate signals. Objects like "mtof" and "stripnote" produce control-rate signals.

cool! any video demos of this in action?

These are quite beautiful. If you are willing, I would to add these examples to the Sporth distribution.

To be honest, you're not missing too much with PolySporth. Actually, you're better off pretending it doesn't exist for now ;) It was an experiment that tried to add concepts like polyphony and note events in time. Despite the serious time investments I put into it, I have never seriously used it. Maybe someday I'll re-examine it and do something interesting with it.

Happy Sporthing,

-P

I am the developer of Sporth. It's nice to see this project listed here. Happy to answer any questions here or on GH.

---

Here are some Sporth links, for those interested:

The main Sporth project page:

http://paulbatchelor.github.io/proj/sporth

Sporthlings: a collection of Sporth compositional etudes:

http://paulbatchelor.github.io/sporthlings/

Sporthlings audio as a youtube playlist:

https://www.youtube.com/playlist?list=PLgEE92LPHEljTLN9gFZr2...

The Sporth Cookbook: documentation on Sporth, as well as some analysis of Sporth patches:

http://paulbatchelor.github.io/proj/cook/

Ha. Your README was very honest at the time :)

It was very encouraging for me to see some ports to C/C++ already in progress. At the time, it was definitely an overwhelming notion. That chunk of JS code looked impenetrable to me.

There aren't any real reasons I have for choosing C89 over C99. Both tend to be very portable, which is very nice if you aren't sure what operating system you are running on (if any, in many situations). I still write many programs using the "-std=c99" flag, but I never find myself in dire need of the extensions, basically honorary ANSI C. For projects like this that just do numerical processing, C89 C really isn't that much more of a hassle.

Yes and no. Perceptually, you don't really need to model everything to get convincing speech sounds. Most of the realism actually comes from performance, and not the mathematical model.

In a way, lips and mouth are accounted for here, but in a more abstract away. The KL model approximates the vocal tract as a series of cylindrical tubes with varying diameters. Segments of the tubes actually correspond to things like the tongue and mouth somewhat. In this model there is a really neat tongue control that manipulates these segments. It's quite expressive!

This model is a 1d waveguide, so it doesn't account for things like the curvature of the tract. More modern vocal modelling techniques include implementing a 2-dimensional waveguide, which does allow for this control.

Correct. WaveNet is a very brute force approach to speech synthesis.

In theory, I think it's doable, but you'd have to build some sort of interface for it. Right now, all that exists are the low level foundations.

The KL model does sing! Max Matthews and Bell Labs produced "Daisy Bell" using a very similar model 1960:

http://www.cs.princeton.edu/~prc/Daisy.mp3

This was the inspiration for HAL to sing Daisy in 2001: A Space Odyssey.

Maybe, maybe not. LPC10 is a 8kHz speech codec optimized for low-bandwith signals. The Kelley-Lochbaum is a full-blown physical model of the tract.

What you put into the filter is important. The LF glottal pulse model used here is a pretty good excitation signal... aspiration noise REALLY makes a difference. It would still sound artificial, but it definitely wouldn't sound metallic.

Do it! I think it's a rewarding exercise.

Also, build a language. Mine is Sporth: http://pbat.ch/proj/sporth.html

More recently, I've been building UIs on top of Sporth called Spigot: http://pbat.ch/proj/spigot

Not directly, no. IIRC, programs like Espeak and Festival use formant synthesis, which would require explicit formant values. Voc models the tract itself... the main parameters are diameters in the vocal tract (which implicitly produce vowel sounds).

It may be possible to go the other way around and analytically derive parameters for Voc that match target formant frequencies. Not sure though...

I found your code last night, and it really freaked me out that there would be another person in the world who would want to make a C port of pink trombone and call it Voc as well.

Voc is pretty much a line-for-line port of PT as well, but I removed some bits like the simplex noise. I also wrote some small utilities to go with Voc, like small plotting programs and some plugins for my audio language for both the whole source-filter model and just the filter.

Still sinking my teeth into the literature. Voice synthesis has a very rich history!

It seems like it would be, right? There are 44 tract-diameters you can modify to shape the vocal tract, and these can be used to generated specific vowel formants. I can imagine you can build a system using deep learning that can find the best parameters to match a steady state periodic pitch. It's a bit how some speech codecs work, like LPC10.

Hey yeah! I actually came across that when I first set out to make my project.

I was going to actually fork off your project, but decided it would be cleaner/faster to do it off the original code since I wanted to write it in ANSI C.

> I'm finding it less readable because of the proportional fonts than if it were equally-commented but in a more conventional monospace programming font.

My initial motivations for using literate programming with Voc was to take advantage of TeX's math mode to express what was happening numerically in code, as well as to have the ability to use BibTex inside the code.

> Also, some samples of making it talk would be good, like: https://en.wikipedia.org/wiki/Voder

At the bottom of the page, there are music examples on Vimeo, with plots of the 44 vocal tract diameters being manipulated in realtime:

https://vimeo.com/220091107

https://vimeo.com/220091290

https://vimeo.com/220091487

My goal was really to build vocalizations, and not necessarily to produce speech. This engine is a bit more low level than that. It could be possible to build a speech engine on top of Voc though... next steps perhaps?

Hey! I'm the author of this thing. Let me know if you have any questions about it.

FYI, the generated C code is now part of the dev branch of Soundpipe here: http://pbat.ch/proj/soundpipe.html, my music DSP library, and it has also made it's way into the develop branch of AudioKit: http://audiokit.io.

Also, check out the original implementation Pink Trombone: https://dood.al/pinktrombone/. It's the perfect interface for this kind of model.

Sorry to see you down. For an approximation of the CHANT software by IRCAM, see the FOF opcode in Csound:

http://www.csounds.com/manual/html/fof.html

The CSound API for Android has been around for a while now. A few years ago I built an app called EtherSurface (my first and only Android app): https://play.google.com/store/apps/details?id=com.zebproj.et...