oh cool, I had a friend who mentioned (I think another one though) program that generated tiny MIDI clips. That would be great for dragging into a DAW and repositioning them around. Nice!
Nope! With those systems you have no way to input accidentals. Here, notes are entered in scale degree, so if you say "4 5 6" you get the 4th, 5th, and 6th scale note, every time. If you later want to transpose to Eb Pentatonic, everything remains musical. The arp can also tranpose by scale notes instead of just semitones too.
Also, there's quite a bit more, all in the docs. There's a ton more there.
What you've just described after "Nope!" is exactly what I mentioned in my post, which is now downvoted I guess. Many many sequencers let you ask for "4 5 6" and adjust for any scale you want. What are you claiming is new here?
Those sequencers do not include Ableton, the Monomachine, Bitwig, Logic, or any that I have experience with. They all use force to scale mechanics that make accidentals impossible.
I suspect Numerology might. I've only seen semitone transpose in most arp implementations, never the ability to work within scale notes. I've never seen an arp that can walk across chords and probabilistically invert them.
The Cirklon had a lot of great ideas including some things like random step transpositions and variables - but generally, in DAWs, it's not something you have access to. Nobody's even tried to get something like Electron parameter locks going, which is a shame, because they are awesome.
I don't have enough karma or levels or superpowers to down vote anyone. I have no idea how this website works in that regard.
Not if you're moving from one kind of scale to another, as you've said you can.
6 7 8 are functionally different to 1 2 etc in an eight-step key.
In fact they're different across different 8 step keys. 6 7 8 in Phrygian are structurally different compared to 6 7 8 in Minor, even though they're the same pitches.
Chords and melodies that use them do not have the same shapes - not because of accidentals, but because they're fundamentally not the same thing and they move through the scale space in different ways.
And in harmonic minor 6 7 8 ascending and descending are different - not just made different with accidentals, but contextually different.
Meanwhile pentatonic melodies can have a pentatonic harmony, or they can have harmonies in other scales and modes. How do you know what "4" is supposed to mean if you're not aware of this?
Of course you can trivially map Thing to Other Thing in Python, but if you don't understand these relationships you're destroying the musical meaning. This is fine for vaguely ambient noodling, but not for building a genuine theory-aware sequencer.
In music theory you don't just play with numbers, you play with style conventions, context, and meaning - and solving that is a much harder problem than you've managed here.
I've been making music with synthesizers for a long time, and I always saw great ideas in DAW tools and in hardware, but never all of those ideas in one place. I wanted more music theory awareness in my compositional tools, like the ability to access easy scale changes. I wanted patterns to be symlinks, and to make it easy to have multiple patterns in a single clip.
I wrote Warp to make it happen. Today there's a Python API that can make full songs, and the work on the UI is getting started, which will be available this Fall.
The Python API doesn't technically even require using a loop, so it should be accessible to programmers who aren't Python experts.
Let me know if there are questions, and if you'd like updates, you can also follow @warpseq on twitter.
Hello there. This looks interesting, but I think that from a promotional standpoint, your website needs screenshots or a video of the user interface for your program. It's cool that you can make this music with it, but I would like to quickly get a feel for how your program is used.
IMO, most people will want to see that before they invest time reading documentation or downloading and installing your software.
Yep, that's true. For now there isn't a user interface and doing some youtubes about the API is definitely planned. the API will remain around forever though, and is useful for generative composition today.
Do a checkout and you can see quite a few song files in the examples dir which should be helpful in getting a feel for it. UI should be out in a few months and will be more photogenic for youtube and will also ship with some demo tracks showing how all of the patterns work.
that's a cool interface - "impossible to play a wrong note" kinda leaves out the ability for intentional accidentals, but... not bad for a lot of things. Bonus points if they get the glowing holograms floating in the air working :)
They actually have some cool features to allow multiple scales and scale changes, so intentional accidentals are promoted. This looks a lot like the Ableton Push controllers besides the direct Ableton integrations. I think the unintentional accidents are what would be missed, and those can be just as good.
Hi folks, I'm Michael DeHaan, and you may remember me from making Ansible.
I know there are a lot of doc frameworks out there but I wanted an easier one, one that allowed me to use HTML and template things with Jinja2, but mostly stay out of my way.
This one requires no RST, no Markdown, and still supports custom themes. Syntax highlighting with Prism.js is built in, and accessed with some Jinja2 macros.
I have at least two projects to write docs for using RockChisel in the next few months, so this is going to get a lot of use. Definitely could use some CSS help, new ideas, and all of that, so if you are interested, stop by the community page on the docs for how to get involved.
First off, it sounds like your playbooks sucked - sorry about that, with great power comes great responsibility. Even as I wanted to make things simple, all things could be abused, and in adding more flexibility I've seen some evil things done in my name :)
So as immutable systems grow - that's a damn good thing. I personally think the docker ecosystem is a trainwreck currently, but that's only my opinion, and doesn't really affect anyone else. But the same concepts have been around for ages in EC2 in immutable systems.
What typically happens is people use the CM tool to provide a higher level abstraction than Bash for describing the image build, so they get features that should have always been in docker files but never were (templates are the biggest one for me).
Further, there is always a need to deploy the "undercloud". Even in heavily containerized microservices setups, there's a need to handle all the magic upgrade fun of upgrading a Mongo cluster, a Cassandra cluster, or a Kafka setup.
Whether we call it configuration management, app deployment, or just a structured way to push scripts around and see what failed, we're going to need those tools.
I believe immutable systems is a fantastic philosophy where it works. It doesn't work everywhere. And CM tools still have a niche for those that want to use them in the build process.
If folks want straight docker files instead, I'm also cool with that.
It's ok if you think of it as such, the veneer over that actually isn't that deep, and that's ok.
The trick is there are some norms you want to express in the language, things like handlers and such, and if you write directly at low level python every time that can be sometimes difficult to maintain a level of consistency (IMHO).
Valid point. I started this about a month ago, and as APIs were evolving I did not want to slow my velocity by having the tests fight against shifting it around.
I suspect the first release will be in about Feburary, but the time to collaborate on working on it is now.
It is designed to be fairly testable, but if you've ever written a similar system, you know that distributed testing of modules on a matrix of 12 platforms IS a trainwreck.
Any units would mostly be proving out the language.
The best way to do that is with a specialized callback, that shares the event stack, and we can then introspect that the events happened in the correct order.
As the callbacks have been changing too much now, writing a boatloat of tests would have been a mistake.
At this point, I'm most interested in feedback on language features, and these will come.
It was an absolute mistake that ansible itself was not more testable at a mock level, a problem made a lot better now by everything being done in one process.
Ansible had the ability to write modules in any language, but this was never really used in practice.
Actually this was meant to describe what we do when we work on OpsMop. It's like "hey, let's all figure out what we want in an ideal universe and build it together". Versus like "hey, you're all my user peeps"
I'm a big fan of the Chef people and they are good folks. Habitat is about a way to distribute applications to remote nodes and is somewhat an alternative to docker. It's kind of apples and carbeutors. Just like Habitat does not compete with Chef, Habitat and OpsMop are also very different things.
