Please join the Simons Foundation and our generous member organizations in supporting arXiv during our giving campaign September 23-27. 100% of your contribution will fund improvements and new initiatives to benefit arXiv's global scientific community.
Imagine waking up each morning knowing the identities of thousands of people who are about to be mugged for thousands of dollars each. You know exactly when and where each of those muggings will take place, and you’ve shared this information in advance with the authorities each day for a year with no outward indication that they are doing anything about it. How frustrated would you be?
A counterfeit check image [redacted] that was intended for a person helping this fraud gang print and mail phony checks tied to a raft of email-based scams. One fraud-fighting group is intercepting hundreds to thousands of these per day.
Such is the curse of the fraud fighter known online by the handles “Brianna Ware” and “B. Ware” for short, a longtime member of a global group of volunteers who’ve infiltrated a cybercrime gang that disseminates counterfeit checks tied to a dizzying number of online scams.
For the past year, B. Ware has maintained contact with an insider from the criminal group that’s been sending daily lists of would-be victims who are to receive counterfeit checks printed using the real bank account information of legitimate companies.
“Some days we’re seeing thousands of counterfeit checks going out,” B. Ware said.
The scams used in connection with the fraudulent checks vary widely, from fake employment and “mystery shopper” schemes to those involving people who have been told they can get paid to cover their cars in advertisements (a.k.a. the “car wrap” scam).
A form letter mailed out with a counterfeit check urges the recipient to text a phone number after the check has been deposited.
Most of the counterfeit checks being disseminated by this fraud group are in amounts ranging from $2,500 to $5,000. The crimes that the checks enable are known variously as “advanced fee” scams, in that they involve tricking people into making payments in anticipation of receiving something of greater value in return.
But in each scheme the goal is the same: Convince the recipient to deposit the check and then wire a portion of the amount somewhere else. A few days after the check is deposited, it gets invariably canceled by the organization whose bank account information was on the check. And then person who deposited the phony check is on the hook for the entire amount.
“Like the car wrap scam, where they send you a check for $5,000, and you agree to keep $1,000 for your first payment and send the rest back to them in exchange for the car wrap materials,” B. Ware said. “Usually the check includes a letter that says they want you to text a specific phone number to let them know you received the check. When you do that, they’ll start sending you instructions on how and where to send the money.”
A typical confirmation letter that accompanies a counterfeit check for a car wrap scam.
Traditionally, these groups have asked recipients to transit money via wire transfer. But these days, B. Ware said, the same crooks are now asking people to forward the money via mobile applications like CashApp and Venmo.
B. Ware and other volunteer fraud fighters believe the fake checks gang is using people looped into phony employment schemes and wooed through online romance scams to print the counterfeit checks, and that other recruits are responsible for mailing them out each day.
“More often than not, the scammers creating the shipping labels will provide those to an unwitting accomplice, or the accomplice is told to log in to an account and print the labels,” B. Ware explained.
Often the counterfeit checks and labels forwarded by B. Ware’s informant come with notes attached indicating the type of scam with which they are associated.
“Sometimes they’re mystery shopper scams, and other times it’s overpayment for an item sold on Craigslist,” B. Ware said. “We don’t know how the scammers are getting the account and routing numbers for these checks, but they are drawn on real companies and always scan fine through a bank’s systems initially. The recipients can deposit them at any bank, but we try to get the checks to the banks when we can so they have a heads up.”
Roughly a year ago, B. Ware’s group started sharing its intelligence with fraud investigators at FedEx and the U.S. Postal Service — the primary delivery mechanisms for these counterfeit checks.
Both the USPS and FedEx have an interest in investigating because the fraudsters in this case are using stolen shipping labels paid for by companies who have no idea their FedEx or USPS accounts are being used for such purposes.
“In most cases, the name of the sender will be completely unrelated to what’s being sent,” B. Ware said. “For example, you’ll see a label for a letter to go out with a counterfeit check for a car wrap scam, and the sender on the shipping label will be something like XYZ Biological Resources.”
But B. Ware says a year later, there is little sign that anyone is interested in acting on the shared intelligence.
“It’s so much information that they really don’t want it anymore and they’re not doing anything about it,” B. Ware said of FedEx and the USPS. “It’s almost like they’re turning a blind eye. There are so many of these checks going out each day that instead of trying to drink from the firehouse, they’re just turning their heads.”
FedEx did not respond to requests for comment. The U.S. Postal Inspection Service responded with a statement saying it “does not comment publicly on its investigative procedures and operational protocols.”
Ronnie Tokazowski is a threat researcher at Agari, a security firm that has closely tracked many of the groups behind these advanced fee schemes [KrebsOnSecurity interviewed Tokazowski in 2018 after he received a security industry award for his work in this area].
Tokazowski said it’s likely the group B. Ware has infiltrated is involved in a myriad other email fraud schemes, including so-called “business email compromise” (BEC) or “CEO scams,” in which the fraudsters impersonate executives at a company in the hopes of convincing someone at the firm to wire money for payment of a non-existent invoice. According to the FBI, BEC scams netted thieves nearly $2 billion in 2020 — far more than any other type of cybercrime.
In a report released in 2019 (PDF), Agari profiled a group it dubbed “Scattered Canary” that is operating principally out of West Africa and dabbles in a dizzying array of schemes, including BEC and romance scams, FEMA and SBA loans, unemployment insurance fraud, counterfeit checks and of course money laundering.
Image: Agari.
Tokazowski said he doesn’t know if the group B. Ware is watching has any affiliation with Scattered Canary. But he said his experience with Scattered Canary shows these groups tend to make money via any and all methods that reliably produce results.
“One of the things that came out of the Scattered Canary report was that the actors we saw doing BEC scams were the same actors doing the car wrap and various Craigslist scams involving fake checks,” he said. “The people doing this type of crime will have tutorials on how to run the scam, how to wire money out for unemployment fraud, how to target people on Craigslist, and so on. It’s very different from the way a Russian hacking group might go after one industry vertical or piece of software or focus on one or two types of fraud. They will follow any method they can that works.”
Tokazowski said he’s taken his share of flack from people on social media who say his focus on West African nations as the primary source of these advanced fee and BEC scams is somehow racist [KrebsOnSecurity experienced a similar response to the 2013 stories, Spy Service Exposes Nigerian ‘Yahoo Boys’, and ‘Yahoo Boys’ Have 419 Facebook Friends].
But Tokazowski maintains he has been one of the more vocal proponents of the idea that trying to fight these problems by arresting those involved is something of a Sisyphean task, and that it makes way more sense to focus on changing the economic realities in places like Nigeria, which has been a hotbed of advanced fee activity for decades.
Nigeria has the world’s second-highest unemployment rate — rising from 27.1 percent in 2019 to 33 percent in 2020, according to the National Bureau of Statistics. The nation also is among the world’s most corrupt, according to 2020 findings from Transparency International.
“Education is definitely one piece, as raising awareness is hands down the best way to get ahead of this,” Tokazowski said. “But we also need to think about ways to create more business opportunities there so that people who are doing this to put food on the table have more legitimate opportunities. Unfortunately, thanks to the level of corruption of government officials, there are a lot of cultural reasons that fighting this type of crime at the source is going to be difficult.”
There are certain rules that even the most extreme objects in the universe must obey. A central law for black holes predicts that the area of their event horizons — the boundary beyond which nothing can ever escape — should never shrink. This law is Hawking’s area theorem, named after physicist Stephen Hawking, who derived the theorem in 1971.
Fifty years later, physicists at MIT and elsewhere have now confirmed Hawking’s area theorem for the first time, using observations of gravitational waves. Their results appear today in Physical Review Letters.
In the study, the researchers take a closer look at GW150914, the first gravitational wave signal detected by the Laser Interferometer Gravitational-wave Observatory (LIGO), in 2015. The signal was a product of two inspiraling black holes that generated a new black hole, along with a huge amount of energy that rippled across space-time as gravitational waves.
If Hawking’s area theorem holds, then the horizon area of the new black hole should not be smaller than the total horizon area of its parent black holes. In the new study, the physicists reanalyzed the signal from GW150914 before and after the cosmic collision and found that indeed, the total event horizon area did not decrease after the merger — a result that they report with 95 percent confidence.
Their findings mark the first direct observational confirmation of Hawking’s area theorem, which has been proven mathematically but never observed in nature until now. The team plans to test future gravitational-wave signals to see if they might further confirm Hawking’s theorem or be a sign of new, law-bending physics.
“It is possible that there’s a zoo of different compact objects, and while some of them are the black holes that follow Einstein and Hawking’s laws, others may be slightly different beasts,” says lead author Maximiliano Isi, a NASA Einstein Postdoctoral Fellow in MIT’s Kavli Institute for Astrophysics and Space Research. “So, it’s not like you do this test once and it’s over. You do this once, and it’s the beginning.”
Isi’s co-authors on the paper are Will Farr of Stony Brook University and the Flatiron Institute’s Center for Computational Astrophysics, Matthew Giesler of Cornell University, Mark Scheel of Caltech, and Saul Teukolsky of Cornell University and Caltech.
An age of insights
In 1971, Stephen Hawking proposed the area theorem, which set off a series of fundamental insights about black hole mechanics. The theorem predicts that the total area of a black hole’s event horizon — and all black holes in the universe, for that matter — should never decrease. The statement was a curious parallel of the second law of thermodynamics, which states that the entropy, or degree of disorder within an object, should also never decrease.
The similarity between the two theories suggested that black holes could behave as thermal, heat-emitting objects — a confounding proposition, as black holes by their very nature were thought to never let energy escape, or radiate. Hawking eventually squared the two ideas in 1974, showing that black holes could have entropy and emit radiation over very long timescales if their quantum effects were taken into account. This phenomenon was dubbed “Hawking radiation” and remains one of the most fundamental revelations about black holes.
“It all started with Hawking’s realization that the total horizon area in black holes can never go down,” Isi says. “The area law encapsulates a golden age in the ’70s where all these insights were being produced.”
Hawking and others have since shown that the area theorem works out mathematically, but there had been no way to check it against nature until LIGO’s first detection of gravitational waves.
Hawking, on hearing of the result, quickly contacted LIGO co-founder Kip Thorne, the Feynman Professor of Theoretical Physics at Caltech. His question: Could the detection confirm the area theorem?
At the time, researchers did not have the ability to pick out the necessary information within the signal, before and after the merger, to determine whether the final horizon area did not decrease, as Hawking’s theorem would assume. It wasn’t until several years later, and the development of a technique by Isi and his colleagues, when testing the area law became feasible.
Before and after
In 2019, Isi and his colleagues developed a technique to extract the reverberations immediately following GW150914’s peak — the moment when the two parent black holes collided to form a new black hole. The team used the technique to pick out specific frequencies, or tones of the otherwise noisy aftermath, that they could use to calculate the final black hole’s mass and spin.
A black hole’s mass and spin are directly related to the area of its event horizon, and Thorne, recalling Hawking’s query, approached them with a follow-up: Could they use the same technique to compare the signal before and after the merger, and confirm the area theorem?
The researchers took on the challenge, and again split the GW150914 signal at its peak. They developed a model to analyze the signal before the peak, corresponding to the two inspiraling black holes, and to identify the mass and spin of both black holes before they merged. From these estimates, they calculated their total horizon areas — an estimate roughly equal to about 235,000 square kilometers, or roughly nine times the area of Massachusetts.
They then used their previous technique to extract the “ringdown,” or reverberations of the newly formed black hole, from which they calculated its mass and spin, and ultimately its horizon area, which they found was equivalent to 367,000 square kilometers (approximately 13 times the Bay State’s area).
“The data show with overwhelming confidence that the horizon area increased after the merger, and that the area law is satisfied with very high probability,” Isi says. “It was a relief that our result does agree with the paradigm that we expect, and does confirm our understanding of these complicated black hole mergers.”
The team plans to further test Hawking’s area theorem, and other longstanding theories of black hole mechanics, using data from LIGO and Virgo, its counterpart in Italy.
“It’s encouraging that we can think in new, creative ways about gravitational-wave data, and reach questions we thought we couldn’t before,” Isi says. “We can keep teasing out pieces of information that speak directly to the pillars of what we think we understand. One day, this data may reveal something we didn’t expect.”
This research was supported, in part, by NASA, the Simons Foundation, and the National Science Foundation.
Taktile creates software products that enable our customers from the financial services industry to use their data to solve business problems they could not solve before.
We are convinced that ML/AI are very powerful tools that can make the world a better and wealthier place. Taktile exists to speed up the adoption of those tools and increase their positive impact on business and society.
Taktile is based in Berlin and New York City. It was founded by machine learning and data science veterans spanning the insurance, banking, and asset management markets. Our team consists of entrepreneurs, researchers, and engineers with a diverse set of backgrounds. Some of us attended top universities such as Harvard, Oxford, and ETH Zurich and some of us have no degree at all. We have accumulated extensive work experience in leading tech companies, top management consulting and the enterprise software sphere. Our backers include Y Combinator, Index Ventures, and stellar angels such as the founders of Looker, GitHub, Mulesoft, Datadog and UiPath.
Building resilience teams with chaos engineering principles.
Last year’s team size reduction was the third in a row that we had to do.
One of the side effects of such a continuous reduction was that the knowledge about our systems was thinly spread: less people but the same number of systems.
As reducing the number of systems was not palatable to Business, we had to mitigate the risk of having a lot of knowledge held in just one person’s head.
Limiting our work in progress has somehow helped spread some of that knowledge, but very slowly and not in all areas.
After watching some chaos engineering video, the idea of applying its principles to build more resilient teams was born in the shape of the Lucky Lotto.
Here is the email to introduce the Lucky Lotto initiative:
Sunday evening.
With very little faith, as every Sunday, you check the number of the Lucky Lotto.
Your heart starts to race, and you sweat like a little piggy.
You check the numbers not twice, but a dozen times.
It has happened. You won the Lucky Lotto!
As you start making plans for those 100.000.000 dollars, one thing is for sure: you will not wake up tomorrow morning to work, neither the rest of your life.
Congratulation! A life of luxury and emptiness awaits you!
Wait, what happened to your Akvo’s team?
Welcome to Akvo’s Lucky Lotto!
Starting last week of September, we are going to start running our own Akvo’s Lucky Lotto.
All of you will have a chance to win, and your team to enjoy the results of your disappearance.
Rules:
- Every Monday a random person will win the Lucky Lotto.
- The winner will work on some side project.
- The winner will be completely unavailable to colleagues and to the rest of Akvo for the week.
- Everybody, including product managers, gets one ticket every week, even if you don’t want it.
- Every time that rule 3 must be broken, the winner must make a note (I will share some doc to do this).
This is nonsense. I would invest all the Lotto money in Akvo and come Monday 9am sharp to work.
So would I! But “You won the Lotto” sounds better than “You were run over by a bus”.
What are those side projects?
Will depend on the skills of the lucky winner, but it could include:
- Platforms work.
- Workflow Improvement work.
- Research.
- Learning.
- Brown-bag session preparation.
- Important but non-urgent work.
- Little side projects for other Akvo departments.
- Collaboration with Hubs.
- Do some “Week of little things” items.
Can I win twice in a row?
And thrice!
Do I have to isolate myself completely?
No. If you are the winner you can still socialise and attend meetings/stand-ups, but you are not allowed to provide input.
I have a very important thing to do that only myself can do and if it is not done the world will be destroyed.
This is basically the point of the exercise. To find those things and ensure that there is somebody else is able to handle them.
Obviously we are not going to jeopardise (completely) our work, but if you find yourself with one of these tasks:
- Make a note.
- Try to bring one of your colleagues to do the task with your supervision.
This is going to force us to become more T-shaped which in the longer run should make the team run smoother and be more adaptable.
If the winner is announced on Monday morning, how can we plan around it?
MUAHAHAhahaha
Let me know if there are any questions, suggestions or comments.
Cheers,
Dan
PS: I wonder if this email will pass your email filters.
The Lotto will give two learning opportunities:
Every Monday 9am we will roll a dice and inform the lucky team.
The winner and myself will meet (but everybody was welcomed), and agree on what will be the objective of the week, which will depend on my TODO list, the winner’s interests, and other teammates’ suggestions.
The teammates’ suggestions proved to be the most interesting.
Three months running the Lucky Lotto showed several instances of a bus factor of one, and gave the teams the opportunity to step up, learn and cover for the missing person’s skills.
As an example, our one and only Android developer won the Lotto the same week that the team was going to fix some major performance issue on the communications between the app and the server. It was a great learning experience for the team.
For the Lucky Lotto winner, it was a very enjoyable week, to either learn something new (Kubernetes, backend development, our deployment pipeline, Cypress, Clojure, …), work on those long desired dev improvements that we never had time for, or to do something different from the usual churn.
These days were a great mirror into where I actually spend my time and if that is the best way to handle the tasks. One of our Product Managers
In addition to the knowledge sharing, we got some cross-pollination and broader-team building as some winners decided to work with the other product team during their Lotto week.
As the ex-platform team lead, it gave me the opportunity to schedule some platform work that was no longer happening, giving the winner the “luxury” of learning some about our platform.
For the rest of the organization, we did some week of little things items, and automated another Finance process (pro-tip: ensure you are on good terms with the people that have the money ).
All looked amazing until the “proper week” …
Panic ensued on the day that THE backend developer of one of the teams won the Lucky Lotto THE week of tight deadlines and unavoidable client promises.
The developer (and his product manager) asked to reroll the Lucky Lotto so that he could have a “proper Lucky Lotto” in a quieter week and for another developer to enjoy it this week.
How many weeks happen to be THE week for THE developer?
A proper Lucky Lotto week?
I realized that the Lotto’s emphasis has been drifting in the wrong direction:
As I have seen some confusion about what is the objective of the Lucky Lotto and its priority, lets review its objective:
Build resilient teams.
That it is.
Why?
So we are less stressed in the future, as we will have a more flexible team.
Working on the most important thing requires this flexibility. Consulting requires this flexibility.
As a generic statement, we are all specialist but not that generalists. We need specialised generalists.
Note that most of us have already done the difficult bit: to become a specialist. Now we just need to do the easy bit: to learn enough of other disciplines. Just enough.
How?
By applying eustress to the team’s week.
In our case, the antifragile practice that we are trying is making one team member “disappear” for a week, and the rest of the team to pick up the missing person’s work.
“Proper” Lucky Lotto week
Reflecting on the past weeks of Lucky Lotto, I think I got wrong what a “proper” Lucky Lotto week would look like. I think I emphasised that the important thing is to not be bothered by anyone, for the team to really to not need you at all.
This was wrong.
A proper and successful Lucky Lotto week is one that, in order of importance:
- You spent a significant amount of time teaching others some of your skills.
- Teaching is more efficient that the team self-learning.
- Some not-easy-to-transfer knowledge gaps are identified.
- Winner gets to do something different.
Again, point 1 is more important than point 3.
Rules (expanded):
- Every Monday a random person will win the Lucky Lotto.
- The winner will work on some side project. Still work.
- The winner will be completely unavailable to colleagues and to the rest of Akvo for the week.
- Everybody, including product managers, gets one ticket every week, even if you don’t want it.
- Every time that rule 3 must be broken, the winner must make a note (I will share some doc to do this):
- Note that this means that rule 3 is a soft-rule.
- There is no “punishment” for breaking rule 3. It is not good neither is bad. It is a fact, and we want to know about it.
- Try to bring one of your colleagues to do the task with you or under your supervision.
- Team should avoid delaying the work for a week.
- Is the winner not working on the most important thing?
- This is a “best effort” initiative:
- Real deadlines have more priority.
- Be practical. It is better to break rule 3 than:
- To waste 5 days of your team’s work.
- To waste 5 days of one team member.
- Miss a partnership related deadline.
- Let one teammate struggling with your task for a week.
The winner’s objective should be helping the team learn and to transfer her knowledge.
I actually don't think specialization is more difficult than generalization, but I thought it will encourage the team.
Lucky Lotto worked pretty well as a fun way to create safe opportunities for the team to learn, spread the knowledge and increase our bus factor, while giving the winner room to break from routine.
An initiative well worth keeping.
But … my efforts to translate the newish business strategy to a technology strategy were bearing fruit, and with the new financial year looming, it was time to start rolling it, which meant a radical change on the Dev team that will absorb all energy and leave little room for experimentation.
This is an article that has been a long time coming, and one that I'm really excited to finally write. Today I want to introduce a project that I've been thinking about and working on for years: Elementary Audio.
Elementary is a JavaScript runtime for writing native audio applications, as well as a library and framework for composing audio signal processes. This is a tool heavily inspired by React.js with which you can write a complete audio DSP application, whether you're targeting web, desktop, mobile, embedded linux, or any of the various native plugin formats for integrating into a modern DAW.
I recently shared a short presentation on YouTube (which I'll show below) that describes some of the problems that I feel we commonly face when writing native audio software, and how Elementary aims to solve those problems. Rather than repeat myself here I want to share part of the story that's not covered as thoroughly in the presentation: the story of how I arrived at the idea of a declarative, functional, reactive model for writing audio DSP, and why I think it's worth betting on.
Before I started working in audio software, I spent many years working primarily in frontend web development, and primarily in JavaScript. I worked on various projects over several years in every flavor of frontend JavaScript application framework before eventually joining the Instagram team at Facebook shortly after their acquisition. There, I had the opportunity to deeply learn, invest in, and even contribute to React.js.
Working with React.js prompted a drastic shift in the way I thought about writing software for one primary reason: it allowed me to reason about my application itself as a pure function of my application state. From there, the actual development follows a remarkably simple perspective: "Given a predefined application state X, I want my app to look like Y, and to behave like Z." That's it; I can think strictly in terms of what my application should be, and defer all of the how to React itself.
Not long after that experience I immersed myself in audio software development with C++ and JUCE, writing creative plugins for computer musicians in their favorite DAWs. To say that this was a complete change of pace is an understatement. Of course, there's quite a learning curve when making such a stark transition, and add on top that I began learning digital signal processing on my own at the same time. But even after I had become comfortable with the domain and comfortable with the tools, I was still moving slowly. It dawned on me, especially after having the opportunity to work with a rock solid team of audio software developers, that it wasn't just me– it seems to me now that the way our industry tends to write audio software is just slow. Not because we're taking our time to get things right, but because we're using the wrong tools.
In audio software, we strongly prioritize performance, and we have to– missing a deadline on the realtime audio rendering thread has drastic consequences. For that reason, of course it makes sense to start with a highly optimized, compiled language like C/C++ (or nowadays maybe Rust) with vector intrinsics and all of that good stuff. Unfortunately, working in C/C++ brings along many challenges that, in other languages, we don't have to even think about– memory management, object lifetimes, thread safety, etc. Now, this is a tradeoff that we simply must make to deliver the types of audio rendering that our industry delivers, and that's fine. Rust and future languages will come along and make this tradeoff more favorable, and I look forward to those developments.
Taking that tradeoff means engaging a whole series of problem domains inherent to writing C++ applications, as we try to build the audio software we set out to ship. The problems that then arise from those domains take real time, and complicate the development process. This is still just part of the tradeoff that we must make when working at the layer of realtime audio rendering. But where I speak of the wrong tooling, I'm really thinking of what happens in the domains where we don't need to take such a tradeoff. It seems to me that we have something of an "everything is a nail when you have a hammer" problem in audio software: once we've committed to writing our audio rendering in C/C++ we carry on to every other edge of our application with the same tools and the same inherent complications. We spend inordinate amounts of time trying to address problems of memory management where we should really just be using a garbage collector. We invite race conditions and synchronization headaches where we should really just be using an asynchronous event-driven engine.
The fact that so many audio software user interfaces are written in C++ drives this point home for me. The types of constraints and requirements that necessitate a language like C++ at the level of realtime audio rendering simply don't exist in the user interface piece of our application. The tradeoff isn't worth it anymore without those requirements, and in my experience, our industry wastes a vast amount of time and resources developing major pieces of our applications with tools that don't make sense. This realization was a major impetus for kicking off my React-JUCE, formerly named Blueprint, project (an update on which is coming soon!).
As it regards writing audio DSP though, this way of thinking didn't start setting in for me until I found myself trying to design the right abstraction for developing my own library of easily composed audio processing blocks. The further I got into that problem, the more I realized that an object oriented approach is fundamentally incompatible with the type of abstraction I was looking for, and that managing object lifetimes compounded the difficulty of the problem drastically. Eventually it dawned on me that the task of composing audio processing blocks is itself free of those realtime performance constraints mentioned above: it's only the actual rendering step that must meet such requirements.
Once this idea took hold, the freedom to explore new abstractions for composing audio signal processes opened up immediately, and I knew right then that I wanted to arrive at an abstraction that brought with it that same perspective that I had grown to love in React.js: "Given a predefined application state X, I want the signal flow through my applicatioin to look like S." And I knew that to get there, I wanted to embrace the following ideas:
Let me share an example that I think demonstrates this approach quite nicely. Imagine that we want to build a 3-band EQ with variable filter shapes (peaking, lowpass, highpass, bandpass, shelves, notch), cutoff, and resonance. To describe the state of our application at any point in time we can use plain objects:
let appState = {
filters: [
{type: 'lowshelf', cutoff: 200, res: 0.717, gain: 2.0},
{type: 'peak', cutoff: 482, res: 2.331, gain: 2.0},
{type: 'peak', cutoff: 2020, res: 1.351, gain: 3.0},
]
};Given such a starting point, we can then use Elementary's functional, declarative API to write the signal flow of our application as a pure function of this state:
function eq3(state, input) {
return state.filters.reduce(function(acc, next) {
let {type, cutoff, res, gain} = next;
switch (type) {
case 'lowshelf': return el.lowshelf(cutoff, res, gain, acc);
case 'highshelf': return el.highshelf(cutoff, res, gain, acc);
case 'lowpass': return el.lowpass(cutoff, res, acc);
case 'highpass': return el.highpass(cutoff, res, acc);
case 'peak': return el.peak(cutoff, res, gain, acc);
case 'notch': return el.notch(cutoff, res, acc);
}
return acc;
}, input);
}Now we have a pure function which describes the signal flow of our application as a function of the application state, and we have a chunk of application state that we can use to invoke said function. The rest, we leave up to Elementary:
core.on('load', function() {
core.render(...el.inputs().map(function(input) {
return eq3(appState, input);
});
});To me this is already a significant improvement over any form of signal composition I've seen in the audio DSP domain, but it's just the tip of the iceberg in Elementary. For example, if we wanted to extend our 3-band EQ into an 8-band EQ, the only thing that needs to change is to describe state for 8 filters rather than 3. If we then wanted to disable 3 of those filters in response to some hypothetical user gesture we could simply remove them from the state.
Now, to really complete this model we have to address the way that applications change over time. It's convenient to write a single static description of your audio processing pipeline and then never have to change it, and surely we already have tools that make that process nicer for the developer. But what happens when we need to address the dynamic behavior of our application? Consider again the above example, where perhaps our app initializes with 8 active filters in our EQ and then the user invokes an action that should disable one of them. What should we do? What should our tools help us do? For example, in a "modern" audio software approach we would likely set the appropriate filter node here to bypass. Personally, I wonder sometimes if the whole idea of bypassing audio processing blocks comes out of the fact that we don't have a good answer to dynamic behavior in audio DSP.
Addressing this situation is perhaps the bread and butter of both React.js and Elementary, and the answer is simple: update your app state, invoke the same function that you've already written, and render it. Under the hood, Elementary will consider both what you've already asked it to render, and what you are now asking it to render, and it will modify the realtime processing operation to affect a change from the current state to the new. The idea of bypass fundamentally doesn't exist: if you no longer need to process a node, you can reflect that need in your app state, omit it from your resulting signal flow description, and Elementary will smoothly remove it from the realtime processing.
lastFilterDisableButton.on('click', function(e) {
// Remove the last filter from the app state
appState.filters.pop();
// Invoke the same render function with our new state.
// Elementary will understand the change and apply it
// dynamically
core.render(...el.inputs().map(function(input) {
return eq3(appState, input);
});
});To me, this point drives home the value of working with such a functional, declarative abstraction. Whether I'm trying to write a static audio signal process that never changes or a flexible, dynamic process that needs to adapt to the user's intentions, the approach is the same. We can think only in terms of what our application should be, and defer all of the how to Elementary.
This post covers the hardware used to develop Playstation One games by major studios back in the day, for the software side see the post on PsyQ.
For the software side of the PS1 development kit (PsyQ) check out this post.
Unlike previous games consoles, Sony decided to use a system that plugs in to a standard PC instead of rolling their own development hardware. This allowed developers to use their PC development experience and tools straight to work when developing playstation games.
EDGE magazine issue 20 had the following to say about this decision:
Perhaps the most ingenious move on Sony’s part was its decision to use the PC as a development platform, enabling it to call on the skills of huge number of developers. Licensees now receive a pair of full-length ISA cards that plug into a normal PC. These two cards contain the entire PlayStation chipset, as well as extra RAM and some logic to enable them to talk to the PC. ‘lt’s great having the system inside the PC,’ reckons Peter Molyneux. ‘With most bulky console development systems it sometimes feels like you’re surrounded by NASA control.’
Such technology doesn’t come cheap, though. PlayStation developers need to cough up £ 12,000 for the full system (which Sony is adamant it doesn’t make money on), although all subsequent software tools and hardware upgrades are free.
But the decision to embrace the PC as a development platform has wider ramifications. Rather than promote a PlayStation-only development path, Sony has seen the advantage of capitalising on the crossover of product between the two platforms. The vast majority of non-Japanese developers are focusing on both formats (in Japan the IBM-compatible PC has a small following).
The PlayStation hardware was condensed by SCE Japan onto two cards that would fit inside a standard PC. The Japanese flew Andy and Martin (From SN Systems) out to Tokyo in June to let them work on the new setup and write new software, so that the bulk of the existing system worked with the new hardware. Apart from extra RAM (eight megabytes of DRAM as opposed to two megabytes in the production PlayStation) and some PC logic, the hardware that slotted into the PC was virtually the same as the production PlayStation.
Original Prototype PS1 given to only a few developers such as SN Systems and was called MW.3, it was only used for very early playstation games. This was basically just an entitre prototype playstation and the hardware differes from the finally released retail playstation, a photo of it was provideded in EDGE issue 20: 
Notice that it looks very similar to the Sony Network Engineering Workstation (NEWS) which was a line of Unix workstation computers that Sony developed in the late 80s and early 90s. It is likely the same machine but with added hardware for Playstation graphics and sound capabilities, more information on the Sony NEWS is available on Wikipedia: Sony NEWS - Wikipedia
The Twin ISA development kit was the most popular development kit used for the playstation: 
The video above shows the DTL-H2000 Development unit which slots into the ISA slot of a PC and contains all the hardware on a retail PS1. These boards were originally sold only to licensed developers only.
The CD emulator card developed by SN Systems (yellow card in above screenshot) is mentioned briefly in the same EDGE UK magazine article:
This enabled the company to design a CD emulator card which connected to a hard drive and output a steady data stream equivalent to that from the CD drive. Now PlayStation code could be written and tested under simulation without having to repeatedly cut expensive gold COs (requiring a specialist Sony machine costing £4000).
The Blue debugging playstation is described in the EDGE UK magazine issue 20:
However, the few differences between the development kit and a production Playstation mean that final testing is done on a blue debugging PlayStation - this is the closest it gets to running on a production console before the complete game is submitted to Sony for duplication.
To go along with the PC based development environment, SN Systems also developed a custom plugin for the back of the playstation debug unit. This turns the debug unit into a full development environment!
There was also development hardware specifically tailored towards Sound engineers so that they didn’t require a full PS1 development kit to test their audio on Playstation hardware.
Due to the quality and relatively low-cost of the official PS1 development kit, it was rare for developers to create their own custom development kits, however a few do exist.
Radical Entertainment had its own customised PS1 console which has its left side cut out and an additional board was added that protruded out that side. This board has additional RAM chips and a port to communicate with the devleopers PC. Presumably the developer would load the full debug executables on to the extra RAM allowing a much more efficient debugging process and would have cost less than the official development kits to produce.
According to Cary Brisebois on Twitter there was software called Bonk that we used for communicating with the development unit [^5].
These photos are kindly contributed by Andrew Earley who recently obtained the development kit from a contact at a recycling center .