Frequently Asked Questions for the Patel synthesizer project

Q:Why is this project called Patel?
A:I named it after the TV character "Synthesizer Patel", it seemed kind
  of apt and I didn't think there'd be any other projects with the same
  name. It's often hard to come up with names, so when I thought of it, I
  stuck with it. I like it.

Q:On what platforms does Patel run?
A:It is currently known to compile and run on Linux. I tried cross-compiling
  it to Windows, but it failed when it came to linking to the Windows
  cross-compiled version of libSndfile (which had taken quite a few tries
  to build). Perhaps it's possible to build *from* Windows with the
  appropriate tools, I have no idea.
  In due time, there will be effort spent on making sure it works on as
  many platforms as possible, including Windows. It is also intended that
  it will run well on embedded systems and very-low-end hardware.

Q:What's a "chiptune" and how is Patel a "chiptune" style synth?
A:Chiptunes are pieces of music made of sounds similar to those produced by
  old style computer music/synthesizer chips such as the Commodore 64's
  "SID" chip, or various other less well known examples (and perhaps to some
  extent, the Yamaha OPL3 etc). A proportion of the "module" files on
  www.modarchive.com  are chiptune style music (mostly the ones labelled as
  such), but there's quite a range of different sounds used.
  Patel attempts to be "chiptune" style by using similar synthesis techniques
  to those I understood such devices to use, but so far I've had limited
  success in getting the sorts of sounds I'm used to hearing in chiptunes.
  This may be due to parts I haven't yet implemented, problems with the
  design, or simply not enough experimentation with what it already does.

Q:How the hell do you use this stupid thing anyway?
A:Ehhh... well currently the prototype version of Patel reads commands and
  parameters for controlling it from standard input, in a primitive file
  format I designed, currently called "PPF". If you have a PPF file that's
  meaningful to Patel, you can then run it from the command line of your
  shell like:
    ./protopatel <someinputfile.ppf
  (substituting in the name of your ppf file)
  Creating those files is a different matter though!! So far, the only ways
  to do that are:
  -Use the Perl script "notestoppf.pl", found in the utils directory. This
   reads in a simple "score" file, and writes out a PPF file for it. It is
   reasonably easy to use, but quite limited.
  -Write the file yourself (or edit a machine-written one) with a text
   editor. This requires you to understand not only the general syntax of
   PPF files, but the meaning of the different commands and parameters as
   understood by Patel. Furthermore, the interpretation of the files is
   subject to which of 3 "modes" Patel's PPF parser is in: it first reads
   a "header" section, then a set of instrument definitions (for as many
   instruments as specified in the header), then a song description. The
   semantics of each of these sections is *different*, although it's all
   valid PPF data.
   As a vague help, there's a couple of PPF files in the distribution,
   but these were more things that I made for testing Patel than as
   examples for users. Sorry.

Q:Why is it so *quiet*?
A:Firstly, I haven't implemented volume controls as yet; secondly, if
  you have say, sounds on only one channel of 8, then the peak amplitude
  is going to be 1/8 of the total. Ouch! Note that volume perception isn't
  linear though, so (I think) it wouldn't *seem* quite as quiet as that.
  Unless you're playing notes near the edges of your hearing range.
  No, I know volume isn't so hard to do, I just haven't got around to it
  yet because it's not as interesting as things like envelopes or FM, and
  then I got bored (it happens, it fades after I go to do something else).

Q:How does the PPF format work?
A:This is too long to go in the FAQ. Please see the file "PPF-intro.txt".

Q:Why did you make PPF rather than use XML or something like that?
A:I don't much like XML, I think it's got its uses, but is bloaty and
  severely overused. PPF gives commands and variables/parameters, which
  suits Patel's requirements for a music description format. It's also
  relatively simple to parse and generate correctly. It's limited in its
  range of applications, but I know that.

Q:Why isn't there a list of what all the PPF commands and variables mean?
A:Because they're all utterly subject to change. That was why I decided to
  use something like PPF rather than a lower-level binary format- I can
  change the semantics quite easily without a complete redesign of the
  syntax. If you bear in mind the use of numerous placeholders in the code
  and mode descriptions, you can try reading the source for Patel; some of
  the included PPF files might help too.

Q:How do you use the "notestoppf.pl" script?
A:If given any filename arguments on the command line, it will read those
  files as input; otherwise, it will read standard input (eg: the keyboard
  or a pipeline). It will write the PPF file to standard output, so you
  should either feed it to Patel through a pipe, or redirect it to a file.
  The form of the score file it reads is given in the comments at the top
  of the script (which is short), but here it is again:
  To start a note playing, use the name of that note in the form A0 or
  G#7 etc (which is incidentally the range of notes Patel supports).
  To release a note, use a ^ symbol.
  To continue either playing or doing nothing, use a  . symbol.
  Spaces and newlines are ignored as with PPF files.

  That's all there is. In other words, if you want to play C3 for 3 ticks
  and then stop for 1 tick, then B2 for 2 ticks and stop for 2 ticks, you
  would do something like:
     C3..^   B2.^.
  Remember, the whitespace is ignored, and is only there for clarity: the
  timing is given by the individual symbols instead: Starting a note,
  releasing it, and doing nothing each take 1 tick of time.
  If however you were to do something like
     D3D3
  then whilst you might *think* that you'd have D3 play for the duration of
  2 ticks, you would have it played twice in a row instead. Where you use
  instruments with envelopes, the difference is very obvious, although
  without it isn't really. As it happens, the output PPF file doesn't
  define an instrument with envelopes, just a default instrument, and you
  would currently have to modify the file yourself to get something more
  interesting.

Q:How long is a "tick" in this script? How do I change the tempo?
A:A "tick" in the above description is synonymous with my usage of "line"
  in the rest of Patel, but as notestoppf.pl is monophonic, the term "line"
  seemed inappropriate and confusing for that. Currently, Patel defines
  the duration of a line as 1/8 of a second, assuming a samplerate of
  44100Hz, and both of these parameters are fixed until some later version.
  In other words, you can't change the tempo yet. It's not yet clear in
  what way I shall implement such a feature.

Q:How can I get more than one track at once using notestoppf.pl?
A:You can't. It writes a PPF file that uses one instrument on one channel,
  for simplicity. Some of the utilities that were planned would allow you
  to merge different PPF files into one, placing each on a different channel
  (in the sense of "track" I mean) but they haven't been written yet because
  I got too tired of working on Patel and wanted to do other things instead.
  When I return to it, such utilities will be amongst the first things I do.
  Seriously. I get how awkward it is to work with PPF ATM.

Q:How do I use a different instrument to the one defined by notestoppf.pl?
A:I'm afraid you have to edit the PPF file by hand. Reading some of the
  example PPF files *might* help, but there's a lot of parameters and
  commands. Reading the source file instrument.c might help too, but it has
  placeholders and code for things that aren't yet implemented, which might
  confuse or mislead you.
  Things like a graphical instrument editor and various tools for changing
  which instruments a PPF file uses are planned for the future.

Q:Can I help?
A:Probably not at the moment. I'm not looking for help with the synth
  itself (possibly later)[Addendum: except perhaps with the RNG, which I
  want to give the same values across all platforms, but not suck like it
  does; for this release I gave up and just used the native rand() from
  the C library].
  As for work on the external utilities, I'm not sure how clear the
  semantics are for the PPF files, so you might well find it to be
  something of a minefield- but if you *really* want to, you can have
  a go. If so, please try to keep your utility fairly basic (it makes it
  easier to keep up to date when things change), with things like pipelines
  and toolchains in mind, and if you're writing it in C, you should
  preferably use the libPPF library I wrote in the libPPF directory.
  *Don't* use the Perl PPF modules I made unless you can fix the damn things,
  they're far too buggy and incomplete.

  If you send me any code, please send source code licensed under the LGPL,
  with copyright information somewhere prominent. I won't redistribute
  closed-source binaries, and any non-LGPL code I will just put on the Patel
  web page separately from the main Patel distribution- and only then if
  it's clearly licensed in terms that allow me to do so.
  (I'll also put any LGPLed code separately on the web page too, until a
  new release of Patel is made in which I can bundle it)
