> Other manufacturers such as Yamaha are guilty of the same kind of interface obfuscation
Everybody agrees the FS1R is a confusing mess although there too I think it's not just the interface but it goes deeper down to them not knowing enough themselves about what can be done with the capabilities of the engine.
In defense of Yamaha, if you read that retrospective I linked in the post [1], you do see that they spent years whittling down their engine to arrive at the DX7 and I think it shows. They did not spend that kind of effort on the FS1R nor did Casio on the VZ-1.
The reality is the oddities of Yamaha's (& Casio's) way of modeling FM (various pre-set "algorithms" with preset routings of phase modulations) are silly once you have a proper modern interface where you can just draw out whatever "routings" you want.
And chained modulations itself is just a poor unintuitive optimization for just running multiple modulations in parallel additively rather than chaining them in sequence. The Yamaha way of doing this is an optimization for old hardware, and is needlessly confusing.
With sub-second build times for individual targets, this causes mk to needlessly recompile files because the target may have the same mtime as the prerequisites.
The article does not talk about security problems. It's about whether your daemon works correctly.
1. Depending on the environment, process supervision can break if there is an unexpected process sitting between the supervisor and the supervisee. The article describes how the switch to PAM forced the introduction of an in-the-middle process responsible for closing the PAM session. The old su used exec, which avoids an in-the-middle process.
2. Su uses the shell of the target user, and will outright not work if the target user has a "nologin" shell.
The article goes on to mention correct workarounds for this like daemontools setuidguid, Runit chpst or just rolling your own exec wrapper.
I'm not sure. Intuitively I would think "phase angle" means "offset into the sine wave lookup table".
If you step through the lookup table with constant size steps, you would get a sine wave. If the steps are not constant size then you get a distorted sine wave. The "rate of change of the phase angle" would then be the step size.
What matters for FM is an instantaneous quantity: the derivative or increment of the instantaneous phase, i.e. how the phase changes from sample to sample.
What is usually called frequency, and has the same value in boring cases like an unvarying sinusoid, is the inverse of the period of the resulting sound as someone would hear it, which is not instantaneous and needs on the order of one period's worth of samples (usually more) to estimate, for a certain definition of period (e.g. interval between zero crossings) or a certain mathematically reasonable calculation (e.g. estimating the frequency of the strongest component from a fixed-length window of past samples).
Author here: This is one reason why I used that term. I was definitely thinking in terms of the 'phase accumulator' looking up the sin table.
Everyone is absolutely right that this is the same as frequency. I think I was used that particular poetic flourish to emphasise how complicated the academic, mathematic explanation is, in contrast with the diagram. Quite likely I picked up that exact phrasing of "phase angle" from some academic literature in particular.
> I think I was used that particular poetic flourish to emphasise how complicated the academic, mathematic explanation is, in contrast with the diagram
is a totally different to what the person you are replying to said
I've edited my post to clarify. It's a reason why I used that term. The second part of my post is not directly addressing what GP said. One of my aims in writing this article was to create something that could be interesting to read, with someone like myself as the target audience. Part of that involves using some artistic flourish.
This is exactly how direct digital synthesis works and the 'step size' is labelled 'frequency' (specifically, frequency in HZ = step size / size of table * update rate)
So far I've only seen the originals, a DX7ii would be hard because I don't have a stash of spares for them so the first couple would likely end up as donors.
You can cast void* to anything you want. With interface{} you get a type check, either through an assertion or a panic. That is a big difference in safety.
Fair point. Maybe there are contrived cases that can get nasty (an interface{}-typed variable boxing a function is possible, not so with any non-empty interface ), but in practice the pathology would be ‘panic’ more than ‘here are the keys to the exploit kingdom’, if this is what you were thinking.
I was thinking more about silence where someone expected a greater degree of compile-time type safety than they really had, or relatedly e.g. the subtleties in JSON encoding / decoding where there is silent data corruption that could fall through the cracks - mostly I feel like I avoid these things by not using interface{}; I certainly did not grasp that without some experience with the language.
I think "everything is a file" also means: everything is addressable by a file path. Per-process namespaces are part of what makes this possible.
In a way it's similar to HTTP REST, which is also organized by file paths, except instead of the HTTP verbs GET, POST etc. you get open, read, write as your verbs.
Looks like Virtualization.framework is newer (Big Sur only) and uses Objective C classes rather than C functions.
I know from the xhyve README that it contains code responsible for booting a Linux kernel, which suggests Hypervisor.framework does not take care of that for you. The Virtualization.framework API on the other hand takes a linux kernel + ramdisk as its inputs.
So it sounds like the framework vftool is built on is more high-level than that of xhyve, and like vftool is Linux-only.
Yeah, Hypervisor.framework is an analogue of KVM (i.e. just manual VM contexts, the caller needs to handle exits to provide virtual hardware). Virtualization.framework is closer to something like QEMU in library form.
I’m using xhyve as well, but I’m having trouble getting it to boot newer kernels. 4.4 era works, (16.04) but 18.04 and 20.04 have various failures. I note that docker is built on xhyve and doesn’t seem to have this issue. So it’s not fundamental, but the fix hasn’t made it back to thx mostly abandoned xhyve.
Ubuntu 18.04 (Linux 4.15) in xhyve works fine for me. I tried to get 20.04 set up a while ago but I gave up because its installer kept flaking out on me, something about the disk if I remember correctly.
I finally wound up with multi pass, but on the Mac it’s limited to ubuntu images, and I occasionally need to spin up arbitrary distros for testing things.
>The biggest issue with ractor support as it stands today would really be getting ALL the libraries any given app uses to support the ractor design.
I wonder if this will create a chicken-egg situation. Without significant Ractor adoption it will be hard to get libraries to adapt. Without essential pieces like Puma supporting (and benefiting from) Ractor there is less reason to for apps to use Ractor.
I am reminded of the difficulties faced by Rubinius, which if I understand correctly, was hampered by too many MRI-compatible libraries not working to get people to switch.
I think the issue is about having to cross a module boundary, which is really about monorepo vs multirepo. You have much more freedom to make breaking changes when you don't need to cross a (repo/module) boundary.
I think the Go module system encourages you to avoid adding unnecessary boundaries. As someone else pointed out already, one of the problems is that you don't find out that boundaries are bad until you hit v2, and then you discover that you have this chunk of technical debt (unnecessary repo boundaries that slow down development) that you didn't know about.
Everybody agrees the FS1R is a confusing mess although there too I think it's not just the interface but it goes deeper down to them not knowing enough themselves about what can be done with the capabilities of the engine.
In defense of Yamaha, if you read that retrospective I linked in the post [1], you do see that they spent years whittling down their engine to arrive at the DX7 and I think it shows. They did not spend that kind of effort on the FS1R nor did Casio on the VZ-1.
[1]: https://web.archive.org/web/20150912075333/http://usa.yamaha...