ChanServ changed the topic of ##yamahasynths to: Channel dedicated to questions and discussion of Yamaha FM Synthesizer internals and corresponding REing. Discussion of synthesis methods similar to the Yamaha line of chips, Sound Blasters + clones, PCM chips like RF5C68, and CD theory of operation are also on-topic. Channel logs: https://freenode.irclog.whitequark.org/~h~yamahasynths
_whitelogger has joined ##yamahasynths
Xyz_39808 has joined ##yamahasynths
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##yamahasynths
<cr1901_modern>
I have an overwhelming urge to make a MOD player after seeing a certain someone's Amiga photos. But not enough time :(
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xyz_39808 has quit [Ping timeout: 276 seconds]
Xyz_39808 has joined ##yamahasynths
andlabs has joined ##yamahasynths
Xyz_39808 has quit [Ping timeout: 250 seconds]
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ej5 has quit [Read error: Connection reset by peer]
andlabs has joined ##yamahasynths
<andlabs>
cr1901_modern: make a mod file instead =p
<superctr_>
MOD is an awful file format
<superctr_>
the "canonical" way of reading notes is to read it as pitch value from the file, then convert back to note number and finally back to pitch again
<fseidel>
having written a mod player years ago, I can confirm it absolutely fucking sucks
<fseidel>
TERRIBLE format
<fseidel>
wastes a ton of space
<fseidel>
the pitch issue superctr_ mentioned
<fseidel>
several bugs have to be emulated or MODs won't play correctly (there's a particularly pernicious one related to jump commands to certain targets)
<fseidel>
notes being stored as frequencies means things sound wrong on hardware with a different clock rate than the song was written for
<fseidel>
effects work in inconsistent ways (some latch, some don't)
<fseidel>
and there's tons of different sources on the internet with variously true and untrue statements about the .MOD format. No one doc is 100% correct
<Lord_Nightmare>
i had an idea for an instrument format which used a small program written in forth or a similar language to produce a waveform; this could be used as a source waveform or an envelope
<Lord_Nightmare>
and you'd link these together to produce instruments, then the compiler would optimize them as much as it could
<Lord_Nightmare>
so it would compile to llvm ir, then do a final optimization pass
<Lord_Nightmare>
its basically a modern version of CSOUND/MusicIV
<fseidel>
that sounds really neat
kode54 has joined ##yamahasynths
Xyz_39808 has joined ##yamahasynths
Xyz_39808 has quit [Ping timeout: 276 seconds]
_whitelogger has joined ##yamahasynths
Xyz_39808 has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<cr1901_modern>
That bad, huh?
<whitequark>
Lord_Nightmare: why llvm?!
<Lord_Nightmare>
because clang already exists and has an optimizer which can be leveraged
<whitequark>
but you said "forth"
<whitequark>
if you wanted to program instruments in c++, sure.
andlabs has quit [Ping timeout: 245 seconds]
andlabs has joined ##yamahasynths
<andlabs>
Lord_Nightmare: LLVM for what?
<andlabs>
whitequark: it can be convenient if you take the time to learn LLVM IR:
<whitequark>
andlabs: i maintain an llvm subsystem
<whitequark>
trust me i know llvm ir
<andlabs>
oh
<andlabs>
=P
<andlabs>
you sounded incredulous is why
<whitequark>
that's why i think it's utter overkill here
<andlabs>
so what does Lord_Nightmare wan to do
<whitequark>
you can write an optimizing compiler in less time it takes you to convert everything to llvm's data model and back
<whitequark>
especially if you start from something like forth, which does not fit well into llvm's data model
<andlabs>
oh Lord_Nightmare wants to write a forth compiler? ok
<andlabs>
sure it won't fit into SSA models well but maybe you can create a stack-machine equivalent to LLVM? =P
<whitequark>
llvm is a compiler from c to machine code at heart
<whitequark>
if you compile from forth to some sort of bytecode there is zero intersection basically
<whitequark>
you want... pretty much an optimizing compiler for your language? which isn't so hard. you can write one in as little as 100 lines
<andlabs>
forth is probably as close to a "low level language" as C is tbh
<whitequark>
sure
<andlabs>
maybe instead of a stack machine equivalent to LLVM
<andlabs>
a forth equivlaent to clang
<andlabs>
that is, a clang-like thing that produces forth instead of llvm ir
<whitequark>
clang is mostly parsing, diagnostics, and template expansion
<andlabs>
I'm not sure what I'm sayign anymore
<Lord_Nightmare>
whitequark: forth was just an example, if I decide to go with llvm the code format itself which each chunk of produces llvm ir would be in any language that compiles into llvm ir natively
<Lord_Nightmare>
or can be coerced into doing so
<whitequark>
Lord_Nightmare: that won't work
<whitequark>
most languages that compile to llvm ir need some sort of runtime
<whitequark>
(including non-freestanding c)
<whitequark>
and most non-c languages that do this also require things like gcs
<Lord_Nightmare>
hmm.
<Lord_Nightmare>
i'm not really sure what the best way is then
<whitequark>
can't say without knowing your restrictions/requirements better
<andlabs>
Lord_Nightmare: what do you want to do?
<andlabs>
sine I'm not sure what you said
<andlabs>
OH
<andlabs>
I didn't miss what you said after all
<andlabs>
oops
<Lord_Nightmare>
the idea is to have some way of producing what amount to self-contained or nearly self contained waveform producing units, which can be attached together in a non-feedback or controlled-feedback orientation
<Lord_Nightmare>
csound/musicIV and cmusic/MusicV allow this, including graphical editors to do it
<andlabs>
okay after reading what you said
<andlabs>
I have no idea
<Lord_Nightmare>
but they're known to be rather slow, though can be done in real time on a modern cpu
<andlabs>
LLVM IR would be nice if you wanted to turn csound into native code for whatever reason, but it likely won't hlp you do general optimizations on math
<Lord_Nightmare>
and done even faster onto a modern dsp
<andlabs>
also look up Formant synthesis
<Lord_Nightmare>
cmusic/musicV is unfortunately a dead language now
<andlabs>
anyway afk
<whitequark>
yes, llvm is unfortunately actually a bad ir for doing things like general loop optimization
<Lord_Nightmare>
csound, which is based on musicIV, is very much alive though
<whitequark>
this isn't even my opinion, chris lattner said so himself in a discussionr ecently
<Lord_Nightmare>
so it sounds like it would be better to find or create an IR which is better for general stuff?
<whitequark>
yes
<whitequark>
i think you should design an ir specifically for this
<whitequark>
80% of the power of an optimizing compiler is in a correct choice of ir that makes desirable transformations easy
<linkmauve>
Do you have documentation on the various directions you can make your IR? I’ve only ever written non-optimising compilers, or optimisations for existing compilers which already had their IR set in stone.
<whitequark>
an IR isn't some sort of special data structure set in stone
<whitequark>
it's just something that is convenient to work on
<whitequark>
for compilers for most languages, this is a control flow and/or data flow graph
<linkmauve>
(The compiler I added optimisations for was Cython, where even creating a new node could mess up expectations from passes much later given all were basically “Python objects”.)
<linkmauve>
(Nowadays I wouldn’t work on a non-typed compiler.)
<whitequark>
I would, but my Python code is extremely defensive
<whitequark>
typechecks and asserts all over the place
<whitequark>
if you ever branch on type of something, else: assert False
<linkmauve>
Other people’s isn’t. :(
<whitequark>
yea
<linkmauve>
Do you have any document explaining the pros and cons of the general classes of IR?
<whitequark>
i'm not sure what "general classes of IR" would even be
<andlabs>
back
<andlabs>
IR is an acronym for 'Intermediate reprresentation'
<andlabs>
for a specififc discussion on what "LLVM IR" does, look up static single-assignment representation
<andlabs>
LLVM IR is not the only SSA-based program representation; the official Go compiler uses a home-grown one
<andlabs>
but asking "what other types of IR are there" is a very broad question
<andlabs>
and in fact, if we're talking about purely mathematical sound waves, I'm not sure if ANY program representations would help here
<TD-Linux>
if you want to see the maximally cursed version of this idea, check out MPEG-4 Structured Audio