Realm of the Practical

Posted on by

Brain storming is easy; I can make things up without being held accountable. However, I need to spend time in the realm of the practical. I won’t stop collecting ideas, but if Slipmat is going to be a reality, I need to know what the issues are. This means lots of research and lots of prototyping and lots of little scripts that test various facets of Python.

For example, creating a graph of Python 3 generators:

#!/usr/bin/env python3

import operator

ksmp = 8
foo = (i * 2 for i in range(ksmp))
foo = (i + 1 for i in foo)
bar = (11 for i in range(ksmp))
foo = map(operator.mul, foo, bar)

print(*foo)

This is interesting to me because the names foo and bar do not receive an array/collect/list of numbers. Instead, they point to generator objects. These generators are not evaluated until print(*foo) is called.

By the way, if my understand or terminology is ever off, please correct me. I’m also here to learn.

3 thoughts on “Realm of the Practical”

  1. Hi,
    I’ve just checked this, and even though they are called generators, they seem to be evaluated when they are created. I’m using python 2.6, so they * operator doesn’t work… What is it for? (Is this the trick?)
     
    Cheers,
    Andrés
     

  2. In Python 3, map() returns an iterator, as opposed to python 2 where map() returns a list. So let’s say you have this expression:

    foo = map(lambda x, y: x + y, [1, 2, 3], [4, 5, 6])

    Printing foo in Python 2 returns [5, 7, 9]. Printing foo in Python 3 returns <map object at 0xd5f190>.

    The * operator in the statement “print(*f00)” prints each value that is yielded by the map iterator object, outputting: 5 7 9

    That said, iterators/generators are completely inadequate for DSP graphs, though they did come in handy for developing a quick prototype.

    I think what might happen is that a graph on the Python side of Slipmat will merely be a description of how unit generators are connected. Perhaps done with XML? Once a graph description is passed to the C/C++ engine, the graph description is parsed, and an actual graph is created. This really isn’t too different to how the Python Csound API works, or how Supercollider creates byte code that is passed to the server.

    And hopefully I answered your question.

  3. Do you mean that python iterators will be wrong for the graph because they are too slow?
     
    Cheers,
    Andrés