This is an attempt at synchronizing Usine to MIDI clocks. Since there's no direct way of controlling the position of Usine's internal clock, the patch calculates the tempo based on the interval between received clocks.
There's an option to delay onset of the synchro for X bars after receiving the MIDI start message - this is mainly for letting the patch have some data for calculation, but can also be used to let Usine wait while the clock master for instance plays an intro.
The tempo is recalculated every 8th note (= 12 MIDI clocks), and the result may jitter a bit. It will also be influenced by the sample rate and block size used.
Feel free to ask questions, make comments or notify me of any bugs.
New add-on MIDI Clock In
thanks for this add-on.
great!
great!
Olivier Sens
www.brainmodular.com
www.brainmodular.com
I've created a new module called "precise time (ms)" which gives the real intern time with a very good precision.
I think it will improve the midi clock detect results.
Next release
I think it will improve the midi clock detect results.
Next release
Olivier Sens
www.brainmodular.com
www.brainmodular.com
I know, Benjamin, you are waiting for that!
Olivier Sens
www.brainmodular.com
www.brainmodular.com
Is there anybody out there that has used this add-on for "real"? In that case I'd like to know how it worked out?
When writing the script, I wasn't really sure whether the calculation should take into account varying tempi. In the end I decided that it should, but if I hadn't, the output could (at least in theory) be more and more precise the longer it ran. That is, if the incomming master clock is stable.
One other idea to better the calculation would be to have the current tempo as a starting point.
If someone wants me to do more with this patch, please tell me, and I'll see what I can do. For that matter; if there are someone that has made a better version of the patch - or has made something that works better - I think that should be in the add-ons instead.
When writing the script, I wasn't really sure whether the calculation should take into account varying tempi. In the end I decided that it should, but if I hadn't, the output could (at least in theory) be more and more precise the longer it ran. That is, if the incomming master clock is stable.
One other idea to better the calculation would be to have the current tempo as a starting point.
If someone wants me to do more with this patch, please tell me, and I'll see what I can do. For that matter; if there are someone that has made a better version of the patch - or has made something that works better - I think that should be in the add-ons instead.
Bjørn S
I think it could be great to have a Midi Clock Pack in the add on: Send and Receive.
But wait for next version, with a more precise timer.
But wait for next version, with a more precise timer.
Olivier Sens
www.brainmodular.com
www.brainmodular.com
I can wait - still working on the PunchInLoops with a lot of new functionality that at least I think can be useful.
Actually, when I put the MIDI Clock In in the add-ons, I wondered whether I should have added the quite simple MIDI Clock Out patch I'm using as well, but dropped it for no particular reason.
When the new timer arrives, I will take a new look at the MIDI Clock patches and possible do a rewrite. Maybe have some different versions of Clock Out, since the philosophy behind the synchro on/off/restart and the MIDI start/stop/continue doesn't quite match.
Actually, when I put the MIDI Clock In in the add-ons, I wondered whether I should have added the quite simple MIDI Clock Out patch I'm using as well, but dropped it for no particular reason.
When the new timer arrives, I will take a new look at the MIDI Clock patches and possible do a rewrite. Maybe have some different versions of Clock Out, since the philosophy behind the synchro on/off/restart and the MIDI start/stop/continue doesn't quite match.
Bjørn S
Hello,
This topic here is my definate next interest in getting my Usine setup on its course. Quite often in our live setup we have a Akai MPC1000 drum sequencer driving our host application.
Previously, whilst using Live, this has worked great.
The MPC1000 sends Midi Clock or Midi Time Code with or without MMC. We have naturally had it setup with Midi Clock and MMC on. Live has been set to EXT = external sync.
The MPC has transport buttons called:
Play Start - Starts from beginning of Bar 1
Play - Continues from where stopped
Rec - Which starts the MPC record, pressed together with Play Start or Play.
Live gets the Tempo pretty much immediately and corresponds with the Metronome / Bar Count built in the MPC. It also follows tempo changes made in the MPC pretty nicely. If there's been a radical change in tempo, it takes it a second to get it right, but it never screws up (or always corrects) the correspondance with the Bar Count. All transport buttons on the MPC do the correct task in Live, except rec does nothing, which is appropriate.
Since I see the potential in Usine, I'd like to get this same thing going here so I can start building from the basis of what we're used to. I checked the Midi Clock In patch but got a whole load of difficulties.
- Play Start works but Play does nothing
- With minimum 1 wait bar the thing starts off okay. With 0 wait bars it starts, but the bars are out of sync, the tempo is "okay", but the bars are out of sync
- With a tempo change in the MPC, the Usine tempo does adjust but again, the bars loose sync
- Also major problem: Pressing stop on the MPC, shuts down the Usine audio engine, meaning if our drum sequencer isn't running, nothing can be heard out of Usine.
bsork to the rescue?
I was just figuring, if the MIDI standard makes it all possible to work in Live, I guess it must be possible in Usine...
Once again, thanks a million kindest people.
antwan
This topic here is my definate next interest in getting my Usine setup on its course. Quite often in our live setup we have a Akai MPC1000 drum sequencer driving our host application.
Previously, whilst using Live, this has worked great.
The MPC1000 sends Midi Clock or Midi Time Code with or without MMC. We have naturally had it setup with Midi Clock and MMC on. Live has been set to EXT = external sync.
The MPC has transport buttons called:
Play Start - Starts from beginning of Bar 1
Play - Continues from where stopped
Rec - Which starts the MPC record, pressed together with Play Start or Play.
Live gets the Tempo pretty much immediately and corresponds with the Metronome / Bar Count built in the MPC. It also follows tempo changes made in the MPC pretty nicely. If there's been a radical change in tempo, it takes it a second to get it right, but it never screws up (or always corrects) the correspondance with the Bar Count. All transport buttons on the MPC do the correct task in Live, except rec does nothing, which is appropriate.
Since I see the potential in Usine, I'd like to get this same thing going here so I can start building from the basis of what we're used to. I checked the Midi Clock In patch but got a whole load of difficulties.
- Play Start works but Play does nothing
- With minimum 1 wait bar the thing starts off okay. With 0 wait bars it starts, but the bars are out of sync, the tempo is "okay", but the bars are out of sync
- With a tempo change in the MPC, the Usine tempo does adjust but again, the bars loose sync
- Also major problem: Pressing stop on the MPC, shuts down the Usine audio engine, meaning if our drum sequencer isn't running, nothing can be heard out of Usine.
bsork to the rescue?
I was just figuring, if the MIDI standard makes it all possible to work in Live, I guess it must be possible in Usine...
Once again, thanks a million kindest people.
antwan
Hi there antwan!
Well, I called it an attempt, didn't I? I knew it was far from perfect, but not that bad...
The problem with creating a patch in Usine - with or without a script - to have it as a slave to another sequencer, is that there is no way of controlling Usine's internal clock. I can only guess how other sequencers do this, but I suppose they increment their internal clocks according to the incoming clocks. Like you said that Live might use a second to "catch up" with radical tempo changes, but it doesn't skip or add any beats so that the bar/beat count is ok.
Since AFAIK the only way to control Usine's timing is indirectly through the tempo on the synchro module, I can't really see how I would go about to make it work 100% - it would end up with being an approximation anyway. I do see possible ways of making the patch a little better, though: I could add a "start tempo", so if you know that the master clock (probably) will start at some BPM, the program could take that into account when calculating eg. the first bar. When dealing with tempo changes, an option would be to calculate the tempo more often. In the script it's being recalculated each 8th note; that is every 12 clocks. Sure enough I tried different ways of doing the recalculations, but ended up with some rather simple stuff, I could retry some of the other ideas I had, but then I will wait until the "precise time (ms)" module arrives and see if that can help.
Now more specificially to your problems:
- Could you use the MIDI Trace option and check that Usine receives a Continue (message 251) when you press Play? I haven't really tried Continue myself and I'm not quite sure that my old beat box is able to send it, but I'm pretty sure that I've handled that bit correctly. In fact, the only difference between Start and Continue in the script is that Start will trigger restart on the synchro and Continue won't.
- As mentioned, I could've maybe added a "start tempo" so the calculations didn't start from scratch each time a Start command was received. Maybe with a manual trigger, so that the last calculated tempo was kept until a trigger was received.
- The trouble with tempo changes is practically the same as with calculating the tempo from start, so I have nothing more to add to that.
- Have you tried to turn of MMC? I've never used MMC, so I don't know too much about it, but I suspect that the reason for Usine's audio engine shutting down could be that the MPC sends some command that makes that happen.
BTW, is using Usine as the MIDI Clock master an option in your setup? It's fairly straight forward to create a MIDI Clock Out patch; the only real problem as I see it being how to distinguish between Start and Continue. I must admit that I've skipped the whole problem by assigning the same MIDI controller and the same qwerty key to both Syncro Start and Restart, so that both Usine and the slave (in my case Reason) starts from the beginning each time. I have just now added the patch I'm using to the Add-ons so you can download it if you like. Personally, I'm using it located in one of the output slots so it's part of the the Master section.
Well, I called it an attempt, didn't I? I knew it was far from perfect, but not that bad...
The problem with creating a patch in Usine - with or without a script - to have it as a slave to another sequencer, is that there is no way of controlling Usine's internal clock. I can only guess how other sequencers do this, but I suppose they increment their internal clocks according to the incoming clocks. Like you said that Live might use a second to "catch up" with radical tempo changes, but it doesn't skip or add any beats so that the bar/beat count is ok.
Since AFAIK the only way to control Usine's timing is indirectly through the tempo on the synchro module, I can't really see how I would go about to make it work 100% - it would end up with being an approximation anyway. I do see possible ways of making the patch a little better, though: I could add a "start tempo", so if you know that the master clock (probably) will start at some BPM, the program could take that into account when calculating eg. the first bar. When dealing with tempo changes, an option would be to calculate the tempo more often. In the script it's being recalculated each 8th note; that is every 12 clocks. Sure enough I tried different ways of doing the recalculations, but ended up with some rather simple stuff, I could retry some of the other ideas I had, but then I will wait until the "precise time (ms)" module arrives and see if that can help.
Now more specificially to your problems:
- Could you use the MIDI Trace option and check that Usine receives a Continue (message 251) when you press Play? I haven't really tried Continue myself and I'm not quite sure that my old beat box is able to send it, but I'm pretty sure that I've handled that bit correctly. In fact, the only difference between Start and Continue in the script is that Start will trigger restart on the synchro and Continue won't.
- As mentioned, I could've maybe added a "start tempo" so the calculations didn't start from scratch each time a Start command was received. Maybe with a manual trigger, so that the last calculated tempo was kept until a trigger was received.
- The trouble with tempo changes is practically the same as with calculating the tempo from start, so I have nothing more to add to that.
- Have you tried to turn of MMC? I've never used MMC, so I don't know too much about it, but I suspect that the reason for Usine's audio engine shutting down could be that the MPC sends some command that makes that happen.
BTW, is using Usine as the MIDI Clock master an option in your setup? It's fairly straight forward to create a MIDI Clock Out patch; the only real problem as I see it being how to distinguish between Start and Continue. I must admit that I've skipped the whole problem by assigning the same MIDI controller and the same qwerty key to both Syncro Start and Restart, so that both Usine and the slave (in my case Reason) starts from the beginning each time. I have just now added the patch I'm using to the Add-ons so you can download it if you like. Personally, I'm using it located in one of the output slots so it's part of the the Master section.
Bjørn S
After getting some sleep, it occured to me that it might be possible to use the pos outlet of the synchro module (which I actually hadn't noticed until Olivier recently mentioned it in another topic) to check whether Usine's clock and bar/beat count matches the incomming clocks, and if not, vary the tempo until it does. I must admit I'm not quite sure how the maths involved would look, but I think I can handle it.
Anyone out there with a better idea?
Anyone out there with a better idea?
Bjørn S
hello.
sounds good. i - of course - also have no idea how the math would look, but perhaps sounds like a way out?
i was just thinking out the box, and thought what if the synchro module had like a 16/32 led IN type of thing, where the whole beat count comes directly from the clock - every nth clock signal > led in - and the tempo DISPLAY would be counted seperately. I.e. it wouldn't be the synchro's tempo in that drives usine but rather a super fast trigger.
maybe this idea makes no sense!
i'm excited whether i might have usine as our platform on our next week's gigs. this might be the key issue though.
bsork, about using usine as the master and mpc as the slave. I had some reason why i found it wasn't a good idea but i will re-investigate.
also start tempo sounds good
antwan
sounds good. i - of course - also have no idea how the math would look, but perhaps sounds like a way out?
i was just thinking out the box, and thought what if the synchro module had like a 16/32 led IN type of thing, where the whole beat count comes directly from the clock - every nth clock signal > led in - and the tempo DISPLAY would be counted seperately. I.e. it wouldn't be the synchro's tempo in that drives usine but rather a super fast trigger.
maybe this idea makes no sense!
i'm excited whether i might have usine as our platform on our next week's gigs. this might be the key issue though.
bsork, about using usine as the master and mpc as the slave. I had some reason why i found it wasn't a good idea but i will re-investigate.
also start tempo sounds good
antwan
hello,
you just point a very dark point for me:
what to do with incomming midi clock, play,stop messages?
on this subjct I really need you experience, and your help.
the only thing I know is:
the stop mesage shouldn't stop the audio engine but only the synchro.
Feel free to ask your requests, i'll do my best to improve Usine.
thanks
you just point a very dark point for me:
what to do with incomming midi clock, play,stop messages?
on this subjct I really need you experience, and your help.
the only thing I know is:
the stop mesage shouldn't stop the audio engine but only the synchro.
Feel free to ask your requests, i'll do my best to improve Usine.
thanks
Olivier Sens
www.brainmodular.com
www.brainmodular.com
Hi Olivier,
You are right, it should basically stop only the synchro/sequencer. The continue message should continue from the exact position where the synchro was stopped, and the Play Start message should start from beginning or if we're in the bounds of a loop in the sequencer or some similar scenario, I guess it should start from the beginning of that loop.
Maybe others have more experiences.
For me, Live is a neat example of how it should work. If you have access to it have a look. A good additional feature in live is in the midi port setup. You can select which Port should be activated to receive Sync, i.e. midi clock.
By the way, bsork, with the current midi clock in patch, when I was playing my usb midi keyboard (axiom 61), setup to play a vsti in another patch (not the master patch with the clock in + metronome), it constantly was screwing with the tempo. The tempo would jump to 2000+ for a moment.
Both used the midi in module, naturally.
I'll think if I come up with more suggestions.
antwan
You are right, it should basically stop only the synchro/sequencer. The continue message should continue from the exact position where the synchro was stopped, and the Play Start message should start from beginning or if we're in the bounds of a loop in the sequencer or some similar scenario, I guess it should start from the beginning of that loop.
Maybe others have more experiences.
For me, Live is a neat example of how it should work. If you have access to it have a look. A good additional feature in live is in the midi port setup. You can select which Port should be activated to receive Sync, i.e. midi clock.
By the way, bsork, with the current midi clock in patch, when I was playing my usb midi keyboard (axiom 61), setup to play a vsti in another patch (not the master patch with the clock in + metronome), it constantly was screwing with the tempo. The tempo would jump to 2000+ for a moment.
Both used the midi in module, naturally.
I'll think if I come up with more suggestions.
antwan
Hi again!
Antwan, your idea with a trigger inlet makes sense to me - in fact it's half way to opening Usine's internal clock for direct manipulation. The big difference I think would be that Olivier had to code the calculations... I don't know why I haven't thought of it before, but the Tap inlet is something of the sort already; it's just expecting quarternotes instead of 96th notes...
I agree with antwan also on how the Start/Stop/Continue should interpreted by Usine, although I'm not quite sure about the within-sequencer-loop scenario. Ideally it should be an option to start from the beginning of the sequence or the current loop.
Olivier, if you're about to do something major with MIDI and synchronizing, there's also Song Position Pointers to take into account. AFAIK, they're constructed in quite the same manner as the VST clock, but I don't know whether they're typically just sent together with a Start message and then followed by Clocks, or whatever. For all that I know, the SPP messages are part of MMC, or is MMC just a way to tell the slave to start, stop, rewind etc, and then the MTC is used for the synchronization?
---
Antwan, is your axiom sending any type of clock related messages? The message numbers are 248, 250, 251, and 252. Of course I can have made a bug in the script even if it's a short little program, but I'm pretty sure it should only do anything when one of the mentioned messages arrive.
Antwan, your idea with a trigger inlet makes sense to me - in fact it's half way to opening Usine's internal clock for direct manipulation. The big difference I think would be that Olivier had to code the calculations... I don't know why I haven't thought of it before, but the Tap inlet is something of the sort already; it's just expecting quarternotes instead of 96th notes...
I agree with antwan also on how the Start/Stop/Continue should interpreted by Usine, although I'm not quite sure about the within-sequencer-loop scenario. Ideally it should be an option to start from the beginning of the sequence or the current loop.
Olivier, if you're about to do something major with MIDI and synchronizing, there's also Song Position Pointers to take into account. AFAIK, they're constructed in quite the same manner as the VST clock, but I don't know whether they're typically just sent together with a Start message and then followed by Clocks, or whatever. For all that I know, the SPP messages are part of MMC, or is MMC just a way to tell the slave to start, stop, rewind etc, and then the MTC is used for the synchronization?
---
Antwan, is your axiom sending any type of clock related messages? The message numbers are 248, 250, 251, and 252. Of course I can have made a bug in the script even if it's a short little program, but I'm pretty sure it should only do anything when one of the mentioned messages arrive.
Bjørn S
I've just constructed a quite simple patch to test how using the Tap inlet works, firing a trigger each 24th clock signal. It works kind of - if it's any better than my earlier effort I'm not quite sure, but the timing seem to drift off slowly between the master and Usine.
Usine generally showed a BPM one more than the master. Not that I think that the tempo readout on that beat box is more precise than Usine. However, I also noticed when using the Tap function the resulting BPM would always show up in whole numbers, so there will certainly be rounding errors when using this nethod.
Usine generally showed a BPM one more than the master. Not that I think that the tempo readout on that beat box is more precise than Usine. However, I also noticed when using the Tap function the resulting BPM would always show up in whole numbers, so there will certainly be rounding errors when using this nethod.
Bjørn S
G'day.
bsork, I would be interested to try that test patch aswell. I'm not sure which external beat box you're using but the MPC at least has a BPM selector with accuracy of 1 decimal. I could try just to see if there's any difference.
Of course one problem is with using the tap inlet. What we would need is something to feed each and every one of the 96 ticks into.
Re: the axiom.
I switched on Trace in the setup and didn't notably see any of the mentioned message numbers appear when playing the axiom. Basically what I was doing was just hitting one note rapidly and then that tempo freakout would happen.
Btw, i'm interested in these MMC codes. I can see they use the message numbers you mentioned. But also they seem to be sysex messages. Should we be using the sysex in/out of the midi in/out modules when constructing these midi clock modules?
Or am I just getting something very wrong!
Lastly,
bsork I tried you're midi clock out module. This seems to be working quite nicely. Right now I'm trying to get on top of that and customize it so that I could be using Usine next week on stage.
Anyway... the midi clock war will continue.
antwan
bsork, I would be interested to try that test patch aswell. I'm not sure which external beat box you're using but the MPC at least has a BPM selector with accuracy of 1 decimal. I could try just to see if there's any difference.
Of course one problem is with using the tap inlet. What we would need is something to feed each and every one of the 96 ticks into.
Re: the axiom.
I switched on Trace in the setup and didn't notably see any of the mentioned message numbers appear when playing the axiom. Basically what I was doing was just hitting one note rapidly and then that tempo freakout would happen.
Btw, i'm interested in these MMC codes. I can see they use the message numbers you mentioned. But also they seem to be sysex messages. Should we be using the sysex in/out of the midi in/out modules when constructing these midi clock modules?
Or am I just getting something very wrong!
Lastly,
bsork I tried you're midi clock out module. This seems to be working quite nicely. Right now I'm trying to get on top of that and customize it so that I could be using Usine next week on stage.
Anyway... the midi clock war will continue.
antwan
And g'dy to you too! Are you Australian?
The beat box I'm using is an old Alesis SR-16. I wasn't very clear when I mentioned the decimals; I was referring to the tempo readout in Usine, which apparantly rounds to whole numbers when using tap. To get a tempo from a manual count-in or similar, that is probably quite ok, but when used for synchronizing to another machine it's not. The SR-16 doesn't have any decimals, but that really doesn't matter. It's the timing of sent clocks that count.
Regarding the tempo freakout, I could try to do something similar tonight to see what happens. If it only happens when you fire of notes rapidly, I suspect that there are something strange happening with the MIDI input queueing. That could happen several places; in the midi interface, in some driver, in Usine, or somewhere else for all I know. One other more possible reason is of course that the bits of code that tries to handle more than one clock message within the same execution is bad...
As I've said, I don't know much about MMC and I don't have anything that sends these messages (unless Cubase does, that is), but what you're saying about a mixture of sysex and clock messages might be true. I think I've read something like that about MMC many, many moons ago, but I'm pretty sure (ca 99.5%) that sysex is of no interest when constructing these patches. I could check a bit around the net on MMC, but not now - I'm supposed to be working.
Hope you get everything up and running to the gig - you must give us a report afterwards!
The beat box I'm using is an old Alesis SR-16. I wasn't very clear when I mentioned the decimals; I was referring to the tempo readout in Usine, which apparantly rounds to whole numbers when using tap. To get a tempo from a manual count-in or similar, that is probably quite ok, but when used for synchronizing to another machine it's not. The SR-16 doesn't have any decimals, but that really doesn't matter. It's the timing of sent clocks that count.
Regarding the tempo freakout, I could try to do something similar tonight to see what happens. If it only happens when you fire of notes rapidly, I suspect that there are something strange happening with the MIDI input queueing. That could happen several places; in the midi interface, in some driver, in Usine, or somewhere else for all I know. One other more possible reason is of course that the bits of code that tries to handle more than one clock message within the same execution is bad...
As I've said, I don't know much about MMC and I don't have anything that sends these messages (unless Cubase does, that is), but what you're saying about a mixture of sysex and clock messages might be true. I think I've read something like that about MMC many, many moons ago, but I'm pretty sure (ca 99.5%) that sysex is of no interest when constructing these patches. I could check a bit around the net on MMC, but not now - I'm supposed to be working.
Hope you get everything up and running to the gig - you must give us a report afterwards!
Bjørn S
ok,ok,ok!!!
The only thing I have to do is to buy a beatbox to really feel how to handle MMC, and MIDI synchro messages...
It's stupid, but I don't have it at home so. My imagination is limited..
as soon as possible!
The only thing I have to do is to buy a beatbox to really feel how to handle MMC, and MIDI synchro messages...
It's stupid, but I don't have it at home so. My imagination is limited..
as soon as possible!
Olivier Sens
www.brainmodular.com
www.brainmodular.com
Hi Olivier, can't you borrow some old rhythm box or something? A lot of synthesizers and multi effect boxes have a midi clock option too. MMC, on the other hand, is not that widely spread. Song Position Pointers is also in use in quite a number of devices, but far from all with a clock option will have SPP as well.
I've taken a look at the MMC specification. Most of the links at midi.org doesn't work tonight it seems, so here's Wikipedia to the rescue: http://en.wikipedia.org/wiki/MIDI_Machine_Control. It appears that MMC is only sysex messages, so what when antwan sees a mixture of sysex and the clock-related messages, it must be because the MPC send both types at the same time.
Googling for info on SPP, I found this link: http://www.borg.com/~jglatt/tech/midispec/ssp.htm which is quite instructive - also follow the link in te lower right corner. According to this page, a SPP message is sent before continue and clocks.
I've taken a look at the MMC specification. Most of the links at midi.org doesn't work tonight it seems, so here's Wikipedia to the rescue: http://en.wikipedia.org/wiki/MIDI_Machine_Control. It appears that MMC is only sysex messages, so what when antwan sees a mixture of sysex and the clock-related messages, it must be because the MPC send both types at the same time.
Googling for info on SPP, I found this link: http://www.borg.com/~jglatt/tech/midispec/ssp.htm which is quite instructive - also follow the link in te lower right corner. According to this page, a SPP message is sent before continue and clocks.
Bjørn S
Hi antwan, the tempo freak out thing happened with me as well. I guess I would've found out earlier if I actually where using the patch myself.
I'm not sure why the script would react to other incomming messages - I thought I had it handled. Anyway, I found a quick solution; filter the messages before they enter the script. That might have an added benefit of reducing the CPU load of the patch as well when lots of midi messages are flying around.
I've uploaded a new version with the changes.
I'm not sure why the script would react to other incomming messages - I thought I had it handled. Anyway, I found a quick solution; filter the messages before they enter the script. That might have an added benefit of reducing the CPU load of the patch as well when lots of midi messages are flying around.
I've uploaded a new version with the changes.
Bjørn S
thanks for the links.
I'm working on it.
I'm working on it.
Olivier Sens
www.brainmodular.com
www.brainmodular.com
Who is online
Users browsing this forum: No registered users and 57 guests