-psycledelics- (http://psycle.pastnotecut.org/index.php)
|- TECH BOARD (http://psycle.pastnotecut.org/board.php?boardid=2)
|-- My ideas for Psycle 2 (http://psycle.pastnotecut.org/threadid.php?boardid=2&threadid=161)


From cubic on 17.02.2002, 17:19:

My ideas for Psycle 2

I had some exams in the last weeks and at some time when I was learning for one of them my head was filled up with lots of ideas concerning the perfect tracker of my choice.

Okay, so here are my thoughts concerning Psycle 2 - architecture.


The program itself should be kept as simple as possible that means the modular character (plugins) of the program should be extended towards the sequencer. This means the following things should be implemented as plugins :

- generators (the same way as we know it now)
- effects (the same way as we know it now)

plus (and that would be the main difference to psycle 1)

- sequence editor plugins (these could be for example tracker, piano roll, controller, step sequencer, arpeggiator, nanoloop-like editor...)

All these things should be dynamic link libraries (for windows this means dll-files).


The sequences created with a sequence editor can have very different time resolutions. Consider for example a controller editor and a step sequencer. It would be nice if the time resolution for the sequence of the controller editor could be much higher than for the one created with the step sequencer (whose resolution could be a quarter note or so).
In spite of this the sequences should have the same format. Therefore every sequence has to have informaton about it's time resolution and probably about the sequenence editor it was created with. These sequences don't seem to be very practical for real time playback. See below for more details on this.
Then a sequence which already holds data should in the best case only be edited by an editor which supports the used time resolution and the included data (note or controller or ???). Otherwise the data which is of a type which can't be edited with the chosen editor must be hidden or trashed in this editor (there are lots of possible variants).
Every editor should be able to open more than one sequence at a time. So there must be a list from which you can choose the sequence to work on. At the same time it should probably be possible to open more than one instance of an editor in order to view different sequences at the same time with the same representation.


Psycle's user interface itself then mainly should consist of these two parts :

- the machine area (which could look the same way as it is now) where you can select generators and effects and connect them and so on

- an area with a time-line (like for example in cubase or logic) where you arrange sequences which you created with a sequence editor. There you can create tracks which you assign to an active machine in the machine area. To keep it simple you then have the possibility to place only one sequence at a time into such a track. It follows that it must be possible to have more than one track associated with one machine in order to have for example a tracker and a controller sequence playing simultaniously.

I think it would be practical to create empty sequences in this time-line. So, in the first place you can open it with every available editor without any quantization/trashing problems.


Okay, now there must be a way to store the arrangement of those sequences. Let's call this thing the main-sequence. It should be able to store every sequence one can create with a sequence editor. If I remember right Cubase for example allows sample exact timing of controller events. So, it seems to be clear that the resolution of this main-sequence should be sample exact meaning for example 44100 positions per second even if this sounds irrealistic for now.
The main-sequence could probably be a 2 dimensional table where every column represents a track in the time-line. So in the cell of the first row and first column we save a reference to the first sequence which is used on the first track together with a sample exact information of the time position when this sequence starts on this track. This has to be done for every track and for every sequence used in the song. Now the sequences itself also could be saved in the very same file.


For playback purposes this is obviously not very handy. Therefore there must be another big sequence, let's call it play-sequence.
Because it would be hard to support sample exact timing in real-time playback it must be possible to determine the time resolution of this sequence. There could be for example a quality slider. According to the setting of this slider the play-sequence is calculated which means :

- we have to look through the main-sequence and quantize it's data in order to be sure that every important information is played. Consider for example a note which is placed at a position in the main-sequence which can't be played by the play-sequence because it's time resolution is too low.
So we have to place this note in a position in the play-sequence which is nearest to it's original place. Now we trash the data if there is already information of the same type and if such data can't be played polyphonically such as controller data for filters.

This play-sequence could be implemented as a multiple linked list. Consider a 3 dimensional table which uses time for the rows and tracks for the columns.
Now the number of rows per second is determined by the quality setting above. 100% quality could for example mean 44100 rows per second if the main sample rate is 44100 Hz which means sample exact quality (this would very probably only be practical for writing the song into a wav-file to achieve the highest possible quality).
Every column now represents a track of the timeline.
It will be possible to create more than one parameter for a machine at a point of time with a single editor. For example you can create a note plus an according velocitiy parameter with a tracker which are placed at the same point of time. So the cell of our 2 dim table whose y coordinate is the point of time mentioned in the sentence before must save in this example the note information plus velocity information. Therefore this cell should consist only of a reference to a linked list which includes the parameters which should be send to the machine at this point of time.
So we have one linked list for the time where every element points to the next discrete point of time used in the play-sequence. The only information of those elements is a reference to the first element of another linked list which represents the tracks. The first element of this list represents the first track which holds parameters to send to a machine at this point of time. One element of this list points to the element of the next used track for this point of time. The only information of an element of this list is a reference to another linked list which finally holds the parameters which should be send to the machine which is adressed by this track. (wow, that was a complicated explanation...)

Changes which are done in an editor should directly affect the play-sequence.


To play the song the following has to be done. We have to go through the play-list which means we go through the linked list representing the points of time. So, when we reach a certain point of time during playback we go to the element in this first linked list which represents this point of time. From there we go to the linked list which represents the tracks used at this point of time and from every element of this linked list we go to the linked list which holds parameters for a machine and send those parameters to the specified machine.


Okay, I think that was enough information for now. Of course, it should be possible to receive and send midi data and so on...


The main advantage of this concept : you can use (and add!!!) the editor which *you* think is practical for a certain task. So use the step sequencer if you want fast results, use piano roll if you want to have exact control of the timing of the data, use the controller editor if you don't want to type in controller changes in the tracker editor


At least for me this would be the thing to go for.

By the way this was my first post on the new forums. And I think it really deserves to be it. Although it is a bit long...


From [JAZ] on 17.02.2002, 19:05:

 

I believe I need time to understand everything in that post, but by now, I believe you've put a bit of light on a part which I forgot, which is concretely these partial sequencers.

When I first thought about it, it was not practical, since you needed to work more (creating them) and it's not clear. when you sequence.

But taking into account they being machines, this means that you can group machines which are sequenced by one sequencer, and others with another, or even a single one, like you say.

for drumloops, usually a 16beat looper is pretty nice, and for synths, a piano roll lets you do "weird" things fast :P

To sequence this, a big cubase-like sequence is the best. You can have there a column for each sequencer machine, and order the patterns there. Also it is very practical to play only one part of the sequence this way.

Auto-assignations, and modifications "on-the-fly" will be "a must".

The problem is that I didn't want to go with excesively windowing, which is what this model goes to.

Also, this simplifies the task, when the Master sequence (That is, Psycle) only needs to send events to the sequencers at certain times, and it can even be independent of the audio. It only needs to know the patterns, and optionally, get information from the sequencers about modifications and such.

Not bad Idea... Might be the way we will go.


__________________
<[JAZ]> Pa pi pa pa pa pi pa.... ;D


From cubic on 25.02.2002, 13:00:

 

quote:
Original by [JAZ]
I believe I need time to understand everything in that post, but by now, I believe you've put a bit of light on a part which I forgot, which is concretely these partial sequencers.




Okay, I will try to clarify things a bit here. Regard this as an first attempt.

quote:

When I first thought about it, it was not practical, since you needed to work more (creating them)


I believe that this concept would speed up the development a lot because everyone could start writing sequencer machines (dll-files) when an interface for them is thought out. It would make the whole project easier because it is split up into more indepandent parts.

quote:

To sequence this, a big cubase-like sequence is the best. You can have there a column for each sequencer machine, and order the patterns there. Also it is very practical to play only one part of the sequence this way.


Yeah, that is what I called the "play-sequence". I think we should have this time-line gui like in Cubase where you arrange sequences which can be modified by the sequencer machines. Every track in this time-line should be assignable to multiple machines. So the play-sequence would actually use one of those tracks as column.

quote:

Auto-assignations, and modifications "on-the-fly" will be "a must".


Absolutely. It must always be possible to play/tweak the generators via midi or pc keyboard.
Editors then would have direct acces to the sequences when recording. Changes in these sequences must directly be "passed" to the play-sequence in order to keep that one up-to-date.
Every editor-sequence should be able to hold editor specific data besides the normal play list. For example it would be nice to remember the chords which were used for an arpeggiator sequence. The play-sequence of course doesn't need these information...

quote:

The problem is that I didn't want to go with excesively windowing, which is what this model goes to.


Would that be such a big problem in terms of usability? I think it would be nice to maximize something like the tracker-editor window so that you could fully concentrate on the tracking process...

quote:

Also, this simplifies the task, when the Master sequence (That is, Psycle) only needs to send events to the sequencers at certain times, and it can even be independent of the audio. It only needs to know the patterns, and optionally, get information from the sequencers about modifications and such.


Yes. No direct audio playback in Psycle needed then.

quote:

Not bad Idea... Might be the way we will go.


I hope so. Don't like the idea to write such a program alone by myself...

Powered by: Burning Board 1.0 Beta 4.5eEnglish Translation by AnnaFan
Copyright 2001 by WoltLab